fix(mimic-iv): apply APS III axillary temperature +1 C correction

[acnimma]

Summary

• Increase axillary temperatures by 1 C before APS III scoring
• Aggregate first-day temperature min/max from vitalsign with site adjustment
• Regenerate postgres and duckdb dialect copies from the BigQuery source

Test plan

• pytest tests/test_transpile.py passes locally
• CI concept build on MIMIC-IV demo

APS III previously ignored temperature site. Axillary measurements are increased by 1 degree Celsius before scoring, matching APACHE III methodology. First-day temperature min/max are derived from vitalsign using the same charttime window as first_day_vitalsign.

[Chessing234]

axillary +1c correction matches the aps iii paper — nice. is the regenerated dialect sql included so bq/duckdb stay in sync?

[acnimma]

postgres + duckdb in PR thank you

[Chessing234]

the main thing missing is evidence that this fires at all. how many first-day rows actually have a temperature_site matching '%axillary%'? the distinct values and counts of itemid 224642 on the demo would settle it — if the site is rarely charted alongside a temperature, or spelled differently, this is a no-op.

there's also a mismatch in what the correction keys off. vitalsign.temperature is an AVG over the charttime group while temperature_site is a MAX over that same group, so when two sites are charted at one charttime the averaged number carries a single site label that doesn't describe it, and the +1 either applies to a blend or gets skipped. applying the correction per-itemid inside vitalsign.sql, before the AVG, keys it to the actual reading.

vital_temp also re-aggregates the whole vitalsign table per stay instead of reading first_day_vitalsign. postgres-make-concepts.sql builds and indexes the firstday tables ahead of the score queries specifically so those "run in minutes rather than hours" — worth a timing before/after, or deriving the site-adjusted min/max in first_day_vitalsign so apsiii keeps reading one row per stay.

and the postgres copy doesn't reproduce: regenerating from this branch's bigquery source with the pinned sqlglot==30.11.0 from requirements-lock.txt gives a 34-line diff against what's committed. main reproduces byte-identically and the duckdb copy matches, so it looks like a different sqlglot version.