Beta verification on a NIC dev cluster and promotion process

[dcmcand]

The runtime verification and process items from the checklist that no CI job can cover (e2e runs on kind without the operator):

Runtime verification on a current NIC dev cluster:

• [A] NebariApp reaches Ready with RoutingReady, TLSReady, AuthReady healthy
• [A] Install succeeds following only the README instructions
• [B] Auth-protected routes reject unauthenticated requests
• [B] Auth-protected routes allow authenticated users with correct group membership
• [B] Health/readiness probes verified on the deployed hub

Pre-sales:

• [A] Pre-sales engineer runs the demo end-to-end and signs off on the happy path
• [B] Pre-sales confirms the pack can be demoed without engineering on the call
• [B] demo_notes in pack-metadata.yaml reflects current gotchas (or is deliberately empty)

Promotion PRs (sequential):

• experimental to alpha: pack owner + pre-sales rep approve; update level, last_promoted_at, last_promoted_pr, README level
• alpha to beta: pack owner + pre-sales rep + tech lead approve; same metadata updates

Consider capturing the auth-route checks as an e2e against the NIC sandbox action already used by the rbac integration tests, so they stop being manual.

Part of #120.