fix: harden alpha-to-beta upgrade path #67

Summary

Harden upgrades from published Alpha releases to v1.0.0-beta.1 and publish an explicit support
contract.

The current authoritative baseline is v1.0.0-alpha.6. A direct
v1.0.0-alpha.6 -> v1.0.0-beta.1 upgrade is a mandatory release gate.

Source releases to evaluate

Evaluate every real public Alpha image/artifact:

• v1.0.0-alpha.1
• v1.0.0-alpha.2
• v1.0.0-alpha.3
• v1.0.0-alpha.4
• v1.0.0-alpha.5
• v1.0.0-alpha.6

Do not treat evaluation as an automatic promise of direct support.

Planned support contract

• Required direct path: alpha.6 -> beta.1.
• Direct compatibility candidates: alpha.4 -> beta.1 and alpha.5 -> beta.1, because those
  releases share the current Alpha 6 migration epoch and post-Alpha-4 persistence/trust
  foundations. They become supported only after the real-image matrix in test: add release upgrade compatibility matrix #68 is green.
• Historical evaluation: direct paths from alpha.1, alpha.2, and alpha.3 must be tested
  with their real published images. A green path may be documented as supported; otherwise
  document the tested staged path through a supported intermediate release.
• Unsupported: development/nightly images, downgrades, running an older image against a newer
  database, and any source/target pair not listed in the final published matrix.

The final support table must be decided from test evidence before #75 closes. Documentation must
name both supported and unsupported paths and include backup/rollback requirements.

State to preserve

• users, roles, permissions, sessions, and relevant authentication state
• Proxy Hosts, Redirect Hosts, Access Policies, Basic Auth accounts, and IP rules
• certificates, private material, trusted CAs, and certificate candidates
• ACME accounts and current retry state
• durable certificate operations/events and host/certificate binding jobs
• DNS provider credentials and application encryption state
• trusted-proxy configuration and canonical management origin contract
• HTTP/3 and current listener/runtime behavior
• audit/access data where the product contract includes it
• desired runtime state, revision state, and live administration-visible operation state

Upgrade behavior

• migrations are deterministic and idempotent across repeated startup
• failed migration/startup is explicit and does not pretend the runtime is healthy
• no silent or partial data loss
• logs are actionable but redact credentials/private material
• runtime reconciliation reaches and verifies the intended final revision
• rollback uses a pre-upgrade backup and the previous exact image; never run the old image against
  an upgraded database

Acceptance criteria

• alpha.6 -> beta.1 passes with a real published Alpha 6 image and is a release gate.
• Alpha 1 through Alpha 5 are evaluated with real published artifacts through test: add release upgrade compatibility matrix #68.
• The final support matrix clearly distinguishes direct, staged, and unsupported paths.
• Fresh Beta installation and repeated Beta startup pass.
• Current Alpha 6 certificate, operation, retry, trust, HTTP/3, and live-state contracts are
  preserved.
• Runtime reconciliation and representative HTTP/HTTPS traffic pass after upgrade.
• Backup and rollback behavior is coordinated with fix: harden backup and restore compatibility #71.
• No credentials or production data are used in CI.

Priority and sequencing

P0. Extends completed historical upgrade work without reopening it. #68 supplies the automated
matrix evidence, #71 covers backup/restore compatibility, and #75 consumes the final documented
support contract.