Server-owned local instance identity isolates concurrent local environments

[brylie]

Problem

A persistent personal Compendium instance and a development or test instance can run concurrently on one machine. Today, each process defaults to the same logical workspace context (default) and the UI always connects to the workspace Yjs room. Database-path isolation helps only when every process is configured perfectly; it does not make the intended boundary explicit or observable.

Scope

• Define a server-owned local instance identity configuration, distinct from future user-facing Spaces and from multi-tenant authentication.
• Resolve the Phase-0 default workspace/shard context from that trusted server configuration at every UI, WebSocket, MCP, persistence, and audit boundary.
• Bootstrap the browser client from server-provided configuration; do not accept a client-chosen workspace identity as authority.
• Make startup diagnostics identify the configured instance and persistence target without exposing secrets.
• Add integration coverage proving two simultaneously running local instances cannot synchronize, observe awareness, search, mutate, or audit each other.
• Document the supported dogfooding/development/test topology, including separate database paths and local addresses.

Non-goals

• User-facing Space creation or switching.
• Multi-user authentication, tenancy, OAuth, or a public deployment model.
• Replacing the shard-boundary decision in Y.Doc sharding strategy for multi-space #13.

Dependencies

Builds on #30, which already introduced an explicit workspace/shard context registry. It must remain compatible with the catalog and shard model selected in #13.

Done when

A personal knowledgebase instance, a development instance, and test harnesses can run concurrently with independently configured identities; an operation in one cannot reach another through Yjs, MCP, UI routing, search, awareness, persistence, or audit state.

[brylie]

Priority unset → P0: concurrent dogfooding, development, and test instances need an explicit server-owned identity before they can be treated as reliably isolated local environments. This is foundational safety work for 0.3.0 and must stay compatible with the shard model selected in #13.