v0.3.7: route collision on GET /health — Overlapping method route panic at boot (ciris-server 0.5.35 ships its own /health)

[emooreatx]

Symptom

Pulling ghcr.io/cirisai/ciris-status:v0.3.7 and starting it crashes immediately:

thread 'main' panicked at /usr/local/cargo/git/checkouts/cirisserver-a454c467160fbe66/cfdac2a/src/compose.rs:617:27:
Overlapping method route. Handler for `GET /health` already exists

Container Restarting (101) continuously. Image-runtime-smoke job evidently didn't run the binary long enough to hit the route-table construction, OR ran against a server build that didn't yet expose /health.

Likely root

v0.3.7's release note (in the bridge handoff message) is explicit about the new shape:

Once it's running, Node B's /v1/health → data.version will report 0.5.35 (even though /health still shows the status 0.3.7)

So the design is:

• ciris-server 0.5.35 owns GET /health (top-level liveness, presumably what the kill-switch / Stage-2 gate reads)
• StatusAdapter wants to own GET /health too (its existing /health that emits the status package version)

The adapter's route registration in compose.rs:617 is colliding with ciris-server's. Whoever registered second is racing the first — axum's Router::merge panics on overlapping method routes.

Suggested fixes

1. Move the adapter's status-package /health to a different path (e.g. /v1/status/health or strip it entirely; the kill-switch wants the server's /health, the status page can use /api/v1/status).
2. Or have the adapter REGISTER UNDER a sub-router prefix that doesn't collide with the embedded server's routes.
3. Add a boot-time smoke that does curl http://localhost:4243/health against the running container, not just a build/import check — same class of CI gap that 0.3.26 — re-pin ciris-server v0.5.98 → v0.5.109 (edge v12.0.0). WIRE BREAK: Node B must roll with the fleet. #28 / glibc raised.

Bridge state

• Node A: ciris-server:0.5.35 up healthy, /health reports 0.5.35 ✓ — Stage-1 gate satisfied for A.
• Node B: docker compose down; previous v0.3.6 deployment removed. Node B is OFF until v0.3.8 (or whatever fix) lands.
• Identity files for Node B (ciris-status-1-hesxz2yiui) preserved on the host volume — when a fixed image comes up, the same canonical key_id resumes.
• Public scoring page (ciris.ai/ciris-scoring/) returns 502 on /api/v1/scoring until Node B is back.

The Stage-2 gate stays unsatisfied for Node B until this is resolved.

cc @emooreatx