Measures page is not scoped to the active MCS — surface availability or refactor inventory model

[blakenan-bellese]

Summary

Lenny's Measures page shows a list of measures that is decoupled from which MCS
(measure server) is currently active. Measures actually live as FHIR resources
(Measure + Library + value-sets) on a specific MCS, so a measure visible in
the UI may not be evaluable on the active MCS — $evaluate-measure will fail
late, with no UI warning beforehand.

This was a non-issue when there was effectively one canonical MCS. With
multi-MCS support shipped in #12 (PRs #283/#290/#292/#293/#294 and #5/#5a),
the assumption breaks silently.

Repro

1. Use the multi-MCS UI (PR #5a) to add a second MCS connection that points to
   an empty HAPI measure server (or any MCS that has not been seeded with
   Lenny's connectathon measures).
2. Activate the new MCS.
3. Open Measures — list looks unchanged.
4. Create a Job against any measure with the new MCS active.
5. Job fails with Library not found / Measure not found from the MCS.

Impact (user-facing)

• False sense of capability. UI shows N measures; only a subset is runnable
  on the active MCS.
• Late failures. User picks a measure, configures groups, submits, waits.
  Failure mode is post-submit instead of inline.
• No "what's where" view. A user with multiple MCSes can't see which
  definitions live where.

Design question

Is the MCS the system of record for measures, or is Lenny?

The seed model treats Lenny as the seed source and the MCS as derived state.
That works for one MCS, breaks for multiple.

Options to consider

1. MCS as source of truth. Query the active MCS's /Measure endpoint and
   render that as the Measures page. Cleanest mental model; biggest behavior
   change; reshapes the upload-bundle workflow.
2. Annotated inventory. Keep the current Measures page, decorate each row
   with availability against the active MCS via cheap probe (HEAD /Measure/{id}
   or extend /health with a measure manifest). User sees green/red per row.
3. Push-on-activate. On MCS activation, sync Lenny's known measures to it.
   Heavy, slow, needs progress UI, introduces a write surface.
4. Probe-on-job-create. Validate measure presence at job-create time, fail
   fast with a clear inline error. Cheapest; doesn't address discoverability.
5. Per-MCS scoping. Track in Lenny's DB which measures were uploaded to
   which MCS; filter the Measures page by active MCS.

Recommendation (initial, open to debate)

Short-term: option 4 (probe-on-job-create) for fast feedback + a banner on the
Measures page noting "Showing all known measures; availability on the active
MCS is not verified."

Medium-term: pick between option 1 (MCS-as-truth) and option 2 (annotated
inventory) after a /plan-eng-review. Option 2 preserves the current upload
workflow; option 1 is the cleanest model but is a UX shift.

Out of scope for this issue

• Per-job MCS override — already addressed in PR v0.0.17.5 feat(jobs): per-job MCS snapshot + active-MCS routing for evaluate_measure #294 (Job.mcs_url snapshot).
• The route-collision fix on /test-connection — folded into PR #5a.

References

• Surfaced during smoke test of PR #5a (multi-MCS frontend).
• Related: chore: refactor Job→connection snapshot to a join table when kind #4 lands #285 (Job snapshot debt) — adjacent but separate concern.
• Architecture: docs/architecture.md — describes the seed-once HAPI model
  this design predates.