Multi-space support

[brylie]

Compendium currently supports exactly one space — everything lives in a single flat pool of Documents and Collections. Multi-space means a workspace can hold several independent top-level spaces a user switches between, each with its own Document/Collection tree.

This is independent of multi-tenant support (#3) — it's not the tenancy/auth boundary, it's an organizational one within a single tenant's workspace (think "separate top-level areas," not "separate customers"). Sequence relative to #3 only if a shared implementation detail (e.g. how permission scoping keys off space) makes that cheaper once #3 is designed — don't assume a dependency by default.

• Data model: a Space concept that owns a set of Documents/Collections (see data-model.md for where this plugs into the existing Record/Document/Collection shapes)
• UI: a space switcher, and the sidebar tree scoped to the active space
• MCP: token scoping extends to space-level, not just individual Document/Collection IDs (see mcp-tools.md)
• Decide default behavior for existing single-space workspaces on migration (auto-create one default space, presumably)

Done when: a user can create a second space, and Documents/Collections in one space never appear in the other's sidebar, search, or MCP token scope.

See prd.md for product rationale.

[brylie]

Blocked by #13 (Y.Doc sharding strategy for multi-space): #13's own body states "Tightly coupled to #6" and its done-when criterion is "#6 can create a second space whose clients only subscribe to that space catalog..." — multi-space support has no CRDT boundary to build on until #13 delivers the shard model. Recording here too since #13 only stated the relationship on its own side. Sequencing: #30 (done) → #31 (P0) → #13 (P0) → #6 (this issue, P1).