Vault join & first-access experience — welcome moment + honest 'waiting for owner key' state

[kipavy]

Part of the team-ux initiative (siblings: #65–#69).

Relates: #67 (invite arrival), #68 (share side), #41 (keyless window), #71 (orientation/hub).

Problem

We've designed how a vault/team invite arrives (#67) and how sharing is made explicit (#68), but the invitee's experience after accepting is undesigned. Today, accept → acceptMyPendingInvitation → the team vault quietly appears/unlocks in the sidebar (VaultSidebar.tsx, joinAndLoadTeamVault). There is:

• No unlock/welcome moment — no "you now have access to <vault>, shared by <owner>; here's what's inside."
• No handling of the Team vault: invitee locked out (no key) when they accept while the inviter is offline #41 keyless window — if the invitee accepts while the owner is offline, they get a silent GET vault-key 404 loop with no key and no explanation (see Team vault: invitee locked out (no key) when they accept while the inviter is offline #41). This is the single worst first-impression in the whole team surface.
• No orientation for a first-time recipient (what a team vault is, that it's synced, who else can see it).

Proposed reflow

• First-access confirmation: on successful join, a clear moment — vault name, who shared it, role granted, and a peek at what's now visible. One dismissible card, not a modal wall.
• Honest keyless state (Team vault: invitee locked out (no key) when they accept while the inviter is offline #41): when the key isn't available yet, show an explicit "Waiting for <owner> to grant access — they need to come online once" state (with the vault visibly locked), instead of a silent failure. Auto-resolve + notify (via Unified team notification inbox — invites, shared sessions & control requests through the bell + toasts #67) when the key arrives.
• Role-aware first view: land the user where their role makes sense (e.g. connect-only → the connections they can use), not a generic empty vault.

Decisions (brainstorm 2026-07-24)

• The keyless window is a product gap, not just a bug — the fix is as much UX (a truthful waiting state) as it is reconciliation. This issue owns the UX; Team vault: invitee locked out (no key) when they accept while the inviter is offline #41 owns the mechanism.

Still open

• Exact copy + surface for the welcome moment (card vs. inline banner).
• Retry/reconcile trigger when the owner comes online (ties to Unified team notification inbox — invites, shared sessions & control requests through the bell + toasts #67 transport).
• What a connect-only invitee should see first.
• Mobile surfacing.