Space-scoped API keys: bind a key to specific space(s)

Have you read a contributing guide?

• I have read CONTRIBUTING.md
• I have searched the existing requests and didn't find any that were similar
• I have considered creating a pull request instead and want to proceed

Clear and concise description of the problem

API keys from the local-link flow (/v1/auth/challenges → /v1/auth/api_keys) are vault-wide: the token reaches every space via GET /v1/spaces, POST /v1/search, and any /v1/spaces/{space_id}/....

This breaks least-privilege for AI/MCP integrations. anytype-mcp exposes the full API to an LLM, so installing it grants the model the entire vault (cf. anytype-mcp#68). Many users want to expose just one space (e.g. a dedicated "AI" space) — currently impossible.

Suggested solution

Add a space dimension to key issuance, extending the scoped-token mechanism from anytype-heart#2021 (AccountAuthLocalApiScope):

1. Accept an optional space_ids: string[] on challenge/key creation. Omitting it keeps current behavior (backward compatible).
2. For a space-scoped key: out-of-scope /v1/spaces/{space_id}/... → 403; GET /v1/spaces lists only in-scope spaces; POST /v1/search is constrained to them.
3. Expose the key's scope via key introspection.

Alternative

Capability scopes from #2021 (Limited/JsonAPI/Full) limit the API surface, not which spaces — they don't solve this.

Additional context

No response

Start by tracing the local-link flow from /v1/auth/challenges to /v1/auth/api_keys, then review the scoped-token mechanism referenced from anytype-heart#2021. Check how GET /v1/spaces, POST /v1/search, space-specific endpoints, and key introspection enforce existing scopes. Done means optional space_ids remain backward compatible while scoped keys restrict all listed operations and expose their scope.