feat(map-layers): register the six geothermal collections

[jirhiker]

Adds the six published geothermal collections to the map and the collections page.

Base branch

This targets chore/bdms-977-978-979-trim-public-ogcapi-catalog (#355), not staging. It builds on the exact-match resolver and the post-trim registry from that PR — based on staging instead, the two would collide hard in useThingLayers.tsx and the collections registry. Retarget to staging once #355 merges (GitHub usually does this automatically; worth confirming).

What was wrong

The catalog publishes these, and nothing in the UI named any of them:

Collection	Title
geothermal_wells_bht	Geothermal Wells — Bottom-Hole Temperature
geothermal_wells_temperature_profile	Geothermal Wells — Temperature-Depth Profile
bht_measurements	BHT Measurements
temp_depth_measurements	Temperature-Depth Measurements
heat_flow	Heat Flow
dst	Drill Stem Tests

The collections page already had a Geothermal group, described as reserved for these collections "when they are published." They are published. The group has always rendered empty.

What changed

All six registered in both registries, collection id as the first candidate and display title as the fallback. Under exact matching the id is what binds; em dashes in the titles normalize away, so either form resolves.

The map's layer panel had no geothermal group at all — getLayerGroupKey would have swept all six into Reference. Adds the group between Climate and Geoscience, matching on geothermal, bht, temp-depth, heat-flow, and an exact ogc-dst. dst is compared whole rather than by substring; three letters collide too easily for includes(). The branch runs before the groundwater check so nothing downstream can claim these keys first.

Popup labels added for all six. Layers are off by default, like every layer except the summary.

Deliberately not done

No layer-specific popup rows. Those need the property names each collection actually carries, and I have the collection ids and titles but not their schemas. The generic property renderer handles them until someone confirms the shapes — worth a look in the preview deploy, especially for bht_measurements and temp_depth_measurements, which may be measurement-per-row rather than one feature per well.

Geometry and volume unverified for the same reason. All six render as default point layers. If temp_depth_measurements is one feature per reading, it could be large, and it may want a different rendering than a plain circle.

waterlevels and water_chemistry are still unregistered — the other two collections with no layer. Left out per instruction; they aren't geothermal.

Verification

Replayed both registries against the catalog: 24/24 layers resolve exactly, the six new ones included. The only unregistered collections left are waterlevels and water_chemistry.

• npm run typecheck — clean
• npm run test:run with the Prism mock up — 359 passed, 16 failed. The 16 are the same integration/api/*.contract.test.ts mock-vs-interface failures present on the base branch and on staging; passing count is up 2 from the two resolver tests added here (em-dash titles, and dst not binding to a collection that merely contains it)
• Biome: per-file diagnostics identical to HEAD on all four touched files — no new lint warnings, no format churn

One note on that last point: biome format --write initially reformatted ~100 unrelated lines in MapPopupComponent.tsx, since these files carry pre-existing format drift (npm run lint only runs the linter, so CI never flagged it). I backed that out with a three-way merge so the diff is only the geothermal change. The pre-existing drift is still there, untouched — worth its own cleanup pass sometime, separately.

🤖 Generated with Claude Code

[github-actions]

Preview Deployment

Preview URL: https://preview-feature-geothermal-map-layers-auejgdbofq-uc.a.run.app

API: https://ocotillo-api-staging.newmexicowaterdata.org