[Feature]: Add scoped API keys and identity discovery for Astra integration

[loveRhythm1990]

Is there an existing issue for the same feature?

• I have checked the existing issues.

Is your feature request related to a problem?

Astra Cloud needs to authenticate an existing Memoria account without implicitly gaining access to that account's memories. Sign-in and cross-product memory sharing must be independent choices.

A deployment master key or an unrestricted personal API key is not an appropriate credential for this integration. Memoria must enforce the delegated permissions itself, including REST and MCP entrypoints, rather than relying only on Astra's UI or runtime checks.

Describe the feature you'd like

Add scoped personal API keys and a versioned identity-discovery contract for integrations such as Astra:

• Support identity:read, memory:read, memory:write, and keys:manage scopes.
• Represent three integration modes: identity-only (no memory sharing), read-only, and read-write. Ordinary Astra connection keys must not receive keys:manage.
• Expose GET /auth/whoami with the authenticated user/key identity, personal/group scope, granted scopes, active/master status, API version, and supported capabilities.
• Enforce scopes and owner isolation on protected REST and MCP operations, including administrative/key-management boundaries.
• Support scoped-key creation, listing, rotation, expiration, and revocation. Rotation must preserve the intended permission boundary.
• Keep existing clients compatible through an explicit legacy-key policy, without silently granting permissions to malformed or explicitly empty scope metadata.

Signing in with an identity-only key must not enable memory access or trigger unnecessary per-user memory database provisioning.

Implementation / design notes (optional)

Use Memoria's existing authentication, API-key storage, and tenant-routing implementations. This is a reusable API capability, not a second Astra-specific account database or authentication system.

Permission checks should happen before memory database provisioning and memory work. Identity/key-management operations should use the shared auth store when a per-user memory database is unnecessary.

Acceptance criteria:

• Identity-only keys can call whoami but cannot read or write memories or manage keys.
• Read-only keys can read owned memories but cannot perform writes, reflection, purge, or key management.
• Read-write keys remain owner-scoped and cannot acquire administrative privileges.
• Revoked/expired keys fail authentication; rotation and legacy-key handling have regression coverage.
• REST and MCP enforce the same permissions, including unsupported or malformed scope metadata.
• Identity-only requests do not provision per-user memory storage.
• Real-database tests and an Astra-to-Memoria scoped-key API v1 contract test cover identity, permissions, and revocation.

Additional information

Related integration PR: matrixorigin/Astra#704

Scope: Memoria's identity/scoped-key API and enforcement. Astra session issuance, CLI/browser login, the website's sharing UI, LLM BYOK configuration, and GitOps deployment belong to their respective repositories.

This issue tracks the Memoria-side implementation and verification; it does not assert that production OAuth or deployment validation is complete.