feat: share credentials across a team

[manojbajaj95]

Summary

Allow multiple identities (team members) to access a shared Vault so credentials — OAuth tokens, API keys, provider configs — can be provisioned once and used by everyone on the team without individual re-authentication.

Motivation

Today every identity owns its own Vault. Teams working on the same project (e.g. a shared CI agent, a shared MCP server pool, or a team of developers hitting the same SaaS API) must each authenticate separately. A team-shared Vault removes this duplication and gives admins a single place to rotate or revoke credentials.

Desired Behavior

• A Principal (team) can own a shared Vault alongside or instead of per-identity Vaults.
• A Vault admin can invite other identities into the Vault (via IdentityClaimRegistry / PrincipalVaultBindingRegistry).
• Invited members can read credentials from the shared Vault; write/admin access is role-controlled.
• The invite flow should be: admin runs authsome vault invite <handle>, invitee accepts with authsome vault accept.
• Credentials in the shared Vault are encrypted such that all authorised members can decrypt them (e.g. per-member key wrapping of the Vault master key).

Work Items

• Define roles: owner, member (read-only), admin (read-write + invite)
• Extend VaultRegistry / PrincipalVaultBindingRegistry to support multi-identity membership
• Implement key-wrapping: wrap the Vault master key once per authorised member using their Ed25519-derived encryption key
• Add authsome vault invite <handle> and authsome vault accept CLI commands
• Add authsome vault members list and authsome vault members remove <handle>
• Enforce role-based access in AuthService and the daemon endpoints
• Audit-log all cross-identity credential reads from a shared Vault
• Update docs with a team-sharing guide

Security Considerations

• The Vault master key must never be transmitted in plaintext; use asymmetric key-wrapping per member.
• Revoking a member should re-wrap the master key for remaining members (key rotation).
• PoP JWT validation must extend to shared-Vault access: the requesting identity must appear in the Vault membership list.