feat(daemon): report api_schema_version in /health + document API compatibility

[mjacobs]

What

Closes the two follow-ups left open by #99: surface the API schema version in
/api/v1/health, and document the compatibility contract for the published
OpenAPI schema.

• api_schema_version in /api/v1/health — the value stamped into the
  OpenAPI document's info.version (daemon.APISchemaVersion), so an external
  client can detect the HTTP API contract at runtime without parsing the
  committed schema. It's distinct from the existing schema_version, which is
  the DB/storage schema (meta.schema_version); the response doc comment spells
  out the difference so the two aren't conflated.
• docs/reference/http-api.md — a Reference page covering how to obtain the
  schema (kata openapi / committed api/openapi.yaml), what the per-release
  snapshot is and isn't, the three version fields, and the compatibility
  expectations (additive changes unsignalled; breaking changes bump
  api_schema_version).

A design note worth a look

api_schema_version is optional in the schema even though current daemons
always send it. A version-detection field has to survive version skew: a client
generated from a schema that includes the field still needs to parse the
/health response of an older daemon that predates it, so an absent value
should read as "older than this field," not a parse failure. Making it required
would also have been a contract change that, by this PR's own documented rules,
should bump api_schema_version — keeping it additive avoids over-signalling.
The net schema delta is a single optional property; the required list is
unchanged.

The committed api/openapi.yaml is regenerated; the existing golden test keeps
it in lockstep with the routes.

Part of #97.

[roborev-ci]

roborev: Combined Review (4a669b5)

Summary verdict: One medium documentation/schema compatibility issue needs resolution; no security issues were found.

Medium

• docs/reference/http-api.md:69: The compatibility guidance says new optional response fields can appear without an api_schema_version change and clients should ignore unknown fields, but the published OpenAPI schemas use additionalProperties: false (for example api/openapi.yaml:1310). Strict clients or validators generated from the schema can reject additive response fields, making those changes breaking despite the documented policy.

  Fix: Either make response schemas permissive for additive fields, or change the compatibility guidance to require an API schema version bump for new response fields / explicitly require clients to disable strict response validation.

---

Panel: ci_default_security | Synthesis: codex, 7s | Members: codex_default (codex/default, done, 2m3s), codex_security (codex/security, done, 12s) | Total: 2m22s