Tests with released midenup binaries #310

Run real released midenup binaries in CI to catch changes that break existing users. Homes built by old releases must upgrade cleanly with the candidate binary, and old releases must keep working with the candidate manifest. See sections 6 and 7 of this comment.

Changes:

• Upgrade test: an old release builds a home, and the candidate binary upgrades and uses it (Home format guard #308).
• Released clients against the candidate manifest.
• Once released, the first midenup release that reads the v3 manifest refuses newer-format homes without changing them.
• Run them on both targets for PRs that change the client or the manifest.
• Run every gate on every midenup release, even when the manifest hasn't changed.
• Measure the runtime and cost of the gates.

Open questions:

• A checked-in client catalog needs a PR after every release and blocks releases until it merges. Could the tests use live release metadata directly instead?
• Which failure would the evidence tooling address (case inventory, hash-bound reports, missing or skipped cases blocking)? Could this logic live in the workflows, the integration tests and update-manifest, instead of a separate tools/release-safety with its own policy file?