[Bug]: Worktree pairing can migrate the live desktop database

Before submitting

• I searched existing issues and did not find a duplicate of this specific failure.
• I included enough detail to reproduce or investigate the problem.

Area

apps/server

Steps to reproduce

1. Keep the installed desktop server running.
2. In a development worktree with a pending migration, run node apps/server/src/bin.ts pair without --base-dir, with no discoverable worktree server.
3. Discovery falls back to the installed server; token creation opens its database using the development checkout's migrations.

Expected behavior

Worktree pairing must not silently target the live install. Minting a token should not run a different checkout's schema migrations.

Actual behavior

An agent trying to pair a dev browser migrated my live database. On September 3, the command returned the installed server on port 3773. The live DB recorded migration 48 (ProjectionThreadMessageContext, unmerged work) and the t3 pair token in the same second: 16:33:46 UTC.

Updating later broke both installed builds: released migration 48 is ProjectionThreadBranchPullRequest, so it was skipped and startup failed on the missing column.

Code path: cli/pair.ts shared-home fallback → EnvironmentAuth.runtimeLayer → SQLite setup → runMigrations().

Related: #8896 covers migration identity validation; this report concerns the pairing command that unexpectedly applies development migrations to live data.

Impact

Blocks work completely

Version or commit

Affected installed builds: 0.0.39 and 0.0.40-nightly.20260907.1346; pairing ran from an unmerged inline-context worktree.

Environment

macOS, Electron desktop; Node CLI invoked from a linked git worktree.

Logs or stack traces

Pairing with MacBook Pro (http://127.0.0.1:3773).
PersistenceSqlError: ProjectionSnapshotQuery.getCommandReadModel:listThreads:query
Error: no such column: branch_pull_request_json

Start in cli/pair.ts and trace the shared-home fallback through EnvironmentAuth.runtimeLayer to SQLite setup and runMigrations(). Reproduce the worktree pairing scenario with an installed server and pending development migration, then verify which server and database are selected. Done means pairing cannot silently target the installed server or apply development migrations to its live database.