Correct three contract claims the published spec got wrong

The `type` query parameter on GET /api/insights/derived carried the eleven
VITALS_BASELINE vitals and described itself as being for that metric only.
SAME_TIME_BASELINE takes a `type` too, and its four cumulative day metrics
were absent from the enum, so a client generated against the spec could not
send them at all. The parameter now publishes the union of both registry
sets and the description says which values belong to which metric. A guard
reads the enum back out of the assembled document and pins it to the
registry, so a type added to either engine reaches the contract with it.

The idempotency wrapper's two 409 arms sent `error` as `{ message }`. That
was the only object-shaped error the application emitted; every other route
sends the documented `{ data, error: <string> }` envelope, which is also
what the spec has always promised. The code was wrong, not the spec. Both
arms now build their response through one helper that sends the string, so
every route under withIdempotency serves the envelope its clients decode.

The hero score-ring comment still described MED_COMPLIANCE as pooled 7-day
adherence. It has been today's dose progress since v1.27.8.

src/lib/dashboard-layout.ts

@@ -406,9 +406,12 @@ function coerceChartOverlayPrefsMap(value: unknown): ChartOverlayPrefsMap {
  *
  *   - `READINESS` / `RECOVERY_SCORE` / `SLEEP_SCORE` resolve through the
  *     derived registry's engines (module-gated like the derived routes);
- *   - `MED_COMPLIANCE` is the pooled 7-day medication adherence from the
- *     canonical compliance engine — the ring that absorbs the retired
- *     hero dose row's information role.
+ *   - `MED_COMPLIANCE` is TODAY's dose progress (taken of scheduled) from
+ *     the snapshot's own `medsToday` block — the ring that absorbs the
+ *     retired hero dose row's information role. The v1.27.7 first cut put
+ *     the pooled 7-day adherence percentage here; it has been today's
+ *     progress since v1.27.8. Resolution lives in
+ *     `@/lib/dashboard/score-rings`.
  *
  * The preference piggy-backs on the layout blob like `chartOverlayPrefs`
  * (a UI affordance, no Prisma migration). The resolver drops unknown ids,