fix(mimic-iv): add missing temperature itemids to vitalsign concept

[acnimma]

Summary

• Add missing temperature itemids to vitalsign.sql (Celsius CASE + site)
• Regenerate postgres and duckdb dialect copies from the BigQuery source

Added itemids (for reviewers)

itemid	Label	Used as
226329	Blood Temperature CCO (C)	temperature (°C)
227632	Arctic Sun/Alsius Temp #1 C	temperature (°C)
227634	Arctic Sun/Alsius Temp #2 C	temperature (°C)
227630	Arctic Sun Temp #1 Location	temperature_site
227631	Arctic Sun Temp #2 Location	temperature_site

Existing 223762 / 223761 (C/F) and 224642 (site) are unchanged.

Why

The vitalsign concept omitted blood/CCO and Arctic Sun/Alsius temperature itemids documented in #1358.

Test plan

• pytest tests/test_transpile.py passes locally
• Itemids listed above present in BigQuery + postgres + duckdb copies
• CI concept build on MIMIC-IV demo

Fixes #1358

[Chessing234]

missing temp itemids are easy to miss. can you list the added itemids in the pr body for reviewers?

[acnimma]

Listed the added itemids in the PR body for reviewers:

• Temperature (°C): 226329, 227632, 227634
• temperature_site: 227630, 227631

All five are in the BigQuery source and the regenerated postgres/duckdb copies.

[Chessing234]

the two site itemids look wrong to me. 227630/227631 are arctic sun probe locations for the cooling device, so folding them into MAX(CASE WHEN itemid IN (224642, 227630, 227631) THEN value END) AS temperature_site puts two different meanings in one column. at a charttime where both are charted the MAX just picks whichever string sorts higher, so temperature_site can end up naming a device probe rather than the site of the 223761/223762 reading sitting next to it. that also silently changes what #2046's LOWER(temperature_site) LIKE '%axillary%' matches, and that's your PR too. could you keep temperature_site on 224642 and give the device probes their own column?

226329 was deliberately commented out on main, so uncommenting it needs a reason in the description. blood/CCO is a continuous core temperature on a small cardiac subset, and averaging it into the same per-charttime AVG as oral/axillary moves vitalsign.temperature for those stays. that propagates through first_day_vitalsign.temperature_min/max into apsiii, sofa, sapsii, oasis and sirs. can you show the demo numbers — how many stays change and how far min/max move?

separately 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 6-line diff against what's committed — the header comment block is three lines here and one line from the pinned transpiler. main reproduces byte-identically and the duckdb copy matches, so it looks like it was generated with a different sqlglot.