Beta verification on a NIC dev cluster and promotion process

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.

Start with the README instructions, pack-metadata.yaml, and the NIC sandbox action used by the RBAC integration tests; run the listed checks on a current NIC dev cluster. Done means the runtime, demo, metadata, approvals, and sequential promotion requirements are verified, with auth-route checks captured as e2e if pursued.