warehouse: the connection registry is process-global, so one server hands the first project's connections to every project #1208

What happens

ConnectionRegistry keeps configs, connectors, pending, and loaded as module-level state (packages/opencode/src/altimate/native/connections/registry.ts). ensureLoaded() loads once for the life of the process. One server process serving two projects therefore hands the first project's connections to both.

Reproduced with two Instance.provide() contexts against the same process:

first:   Instance.directory = .../project-a   →  path = .../project-a/warehouse.db
second:  Instance.directory = .../project-b   →  path = .../project-a/warehouse.db

Cached connectors make it worse: they are keyed only by connection name, so project B can be handed a live connector already open against project A's warehouse.

Why it matters now

This predates #1204 — before it, the base was the server's launch directory for everyone, so every project was equally wrong. #1204 made resolution correct for whichever project loads first, which is the right answer for the single-project case that covers nearly all real use. The residue is that the behaviour is now "first request wins" rather than "uniformly wrong", and that is worth closing properly rather than leaving in a comment.

Two related gaps in the same area:

• Instance.directory is the request's working directory, not Instance.worktree. A request naming a nested directory looks for .altimate-code in that nested directory rather than at the project root.
• run --attach without --dir sends no directory (cli/cmd/run.ts:408), so the server falls back to its own cwd (server/server.ts:281).

What a fix looks like

Make the registry state instance-scoped rather than module-scoped — keyed by Instance.directory, or held in the instance context — so each project loads and caches its own configs and connectors. Connector cache keys need the project in them too.

Not a blocker for #1204

#1204 documents this limitation in projectRoot()'s doc comment and does not regress it. Filing separately because the fix is a state-ownership change across the whole registry, not a path-resolution change.