Document the climate zone keys, in both idioms

[samuelduchesne]

Draft, and blocked on the release by design. Read the last section before deciding this is broken.

Pairs with idfkit#203 and idfkit-js#54.

What was wrong

docs/weather/station-search.md told a reader to filter by climate zone "using a plain list comprehension", and showed:

zone_4a = [s for s in index.stations if s.ashrae_climate_zone.startswith("4A")]

On the bundled index that is the defect the two library pull requests exist to remove. startswith("7A") returns 1,262 records labelled 7A - ASHRAE Climate Zone could not be determined, and startswith("8A") returns 900. Neither 7A nor 8A is an ASHRAE zone, because zones 7 and 8 carry no moisture suffix.

The site was publishing the workaround as the method.

What this does

• Rewrites the Python snippet onto climate_zone and climate_zone_determined.
• Adds the TypeScript tab, so the section stops being silently monolingual.
• Adds a warning block carrying the two traps with their counts: the invented 7A and 8A, and that the suffix is [ABC] and not [AB], which costs 1,653 marine-zone stations.
• Amends the cross-reference higher up the page, which pointed at the old section.

The TypeScript snippet is not authored here. docs/snippets/js/ is vendored from idfkit-js at the pinned docs level and sync_js_artifacts.py --check fails on a file that exists only in the vendored copy. It is written and executed in idfkit-js#54, asserting the counts rather than merely running: 7,952 for 4A, 115 for 4C in Washington, 2,162 undetermined, and zero for 7A. It reaches this page when the docs level moves.

Why CI is red, and why the fix is not the page

make check runs pyright over docs/snippets, and it reports four errors, all of the form:

No parameter named "climate_zone"  (reportCallIssue)

That is correct. This repository pins idfkit==1.0.0-rc.3, and the keys ship in the next release. bump-idfkit.yml states the rule for exactly this situation: "a red result means a page describes an interface the new version does not have. The fix is the page. Never relax the check, never pin the level back, never merge past it."

Here the direction is reversed. The page describes an interface the pinned version does not have yet, and the page is right about the version it will describe. So the fix is the pin, not the page, and this merges with the bump.

What still needs doing on this repository, separately

• [tool.idfkit.governance] reads governance-2026.14. It is now at governance-2026.16, two levels behind, which predates this work.
• docs/weather/browse/ needs nothing: it is gitignored and recopied from the installed distribution by scripts/copy_shipped_assets.py on every build, so the browser fix in idfkit#203 arrives with the pin.

The gap that let this happen

Constitutional Principle VI says "Changing a documented API MUST break the documentation checks." It does, and bump-idfkit.yml is built on it. But an addition breaks nothing: the old list comprehension still type-checks perfectly against a version that has the new keys, so a release that adds public API can leave a page teaching the superseded idiom and every gate stays green.

Nothing currently fails when a name in the naming register has no page. That is a mechanism gap rather than something this pull request should quietly fix, and it is worth its own discussion.