Define the release manifest contract

[amc-corey-cox]

The release manifest is the single mutable thing in the whole design, and everything else inherits its correctness. ARCHITECTURE.md describes the pattern — each release publishes artifacts under new paths together with a manifest naming them, services resolve it at startup — but nothing defines its shape or who writes it.

Everything downstream depends on getting this right:

• Cache validity. Immutable paths below the manifest are what make infinite TTLs correct at every layer.
• Rollback. Repointing at the previous manifest is the entire rollback story.
• Staleness. Files never changing under a given name is what makes staleness detection unnecessary rather than merely deferred.

What needs deciding:

• What the manifest names — Parquet artifacts certainly, but also whether it covers the Solr collection alias so that a release is one coherent thing rather than two that can drift
• Where it lives and how services discover it, given that it is the one object that must be resolvable without already knowing the release
• Who writes it, which is really the question of where the release layer lives
• Whether it carries provenance about its own build — the execution provenance from Emit PROV-O provenance records during harmonization linkml/dm-bip#352 is a natural fit and would make a release self-describing
• Rollback semantics when artifacts and the search index move together

The release layer itself is out of scope for now. The contract isn't — it's the interface every other component resolves through, and it should be settled before the read-pattern work in #14 hardcodes assumptions about how artifacts are found.