fix: harden alpha-to-beta upgrade path

[RentnerKev]

Summary

Harden upgrades from publicly released Alpha versions to
v1.0.0-beta.1.

Supported source versions should include the public Alpha releases that
are technically reasonable to support.

At minimum evaluate:

v1.0.0-alpha.1
v1.0.0-alpha.2
v1.0.0-alpha.3

Goals

Preserve:

• users
• roles
• permissions
• Proxy Hosts
• Redirect Hosts
• certificates
• Trusted CAs
• Access Policies
• access/audit data where applicable
• desired runtime state
• encryption state
• relevant settings

Failure Behavior

Migration failure must:

• fail clearly
• avoid silent data loss
• avoid partially pretending startup succeeded
• provide actionable logs

Acceptance Criteria

• Alpha → Beta upgrade path verified
• fresh Beta install still works
• repeated startup remains safe
• migrations are deterministic
• runtime reconciles after upgrade
• production appliance upgrade path tested

Priority

P0

Dependencies and sequencing

Extends the completed Alpha-1-to-Alpha-2 work in #34; do not reopen or duplicate that completed scope. #68 validates the supported Alpha-to-Beta upgrade contract. Coordinate persistence/encryption and backup compatibility with #71. Final Beta state, including new feature data, must be covered before #75.

Alpha 4 prerequisite

Also evaluate v1.0.0-alpha.4 as a source release. Preserve its certificate candidates, durable operations/events, retry state, host binding jobs, trusted proxy configuration, and canonical management origin. #85 owns Alpha 3 -> Alpha 4; this issue still owns the Alpha -> Beta transition.