feat(vscode): pair with pairing URL

[bulgadev]

Child PR of the VS Code overlay (#175), per the client-overlay workflow.

What

Adds a "T3 Code: Pair with Server…" command (t3Code.pair) that accepts a full pairing URL (http://host:port/pair#token=…) or a bare pairing token, exchanges it for a bearer access token via the OAuth token-exchange endpoint (bootstrapRemoteBearerSession), and stores it in SecretStorage under the existing t3Code.serverBearerToken key — so ensureConnected picks it up as the bearer tier with no other wiring changes.

Removes the need to hand-exchange tokens with curl before using Set Server Bearer Token.

Changes (all in apps/vscode/)

• src/pairing.ts — pure classifyPairingInput (URL vs bare token) + describeTokenExpiry helpers; no vscode import
• src/pairing.test.ts — unit tests, including composed cases against the real resolveRemotePairingTarget
• src/t3Client.ts — exchangePairingCredential(httpBaseUrl, credential) beside connectWithBootstrap (exchange only, no connect)
• src/extension.ts — command registration; reuses readDesktopServerUrl/serverCandidates for the bare-token fallback host
• package.json — command + activation event

Pairing links are single-use with a 5-minute TTL, so the exchanged access token (30-day TTL) is what gets persisted; on expiry the user re-pairs.

Local gate (green)

• pnpm --filter t3-code test — 40 tests, 11 files
• pnpm exec vp check — clean
• ELECTRON_SKIP_BINARY_DOWNLOAD=1 pnpm exec vp run -r --cache --log labeled typecheck — clean

[omegent-app]

Thanks for this, @bulgadev — it's shipped. 🎉

Merged as #351 (4a13d9643) on fork/dev, with your Co-authored-by trailer intact on the commit.

Closing this one only because it targets fork/vscode, an overlay branch that has since been frozen
and drained: this repository moved to a stable, never-rebased fork/dev as the contributor target
and release source, so the branch your PR was based on no longer receives work. Since the PR came
from your fork, we couldn't rebase it in place — hence the port. Nothing was rejected, and the
change went in essentially as you wrote it.

Two things were added on review before merge, both worth knowing about:

• The bearer token is now pinned to the server that issued it. Pairing resolves an endpoint from
  the URL, but ensureConnected() walks the desktop and configured candidates and would have offered
  that token to each in turn — so pairing with server B could disclose B's token to server A. The
  paired endpoint is now the first connection candidate and the only one the token is sent to.
  Hand-entered tokens stay unpinned, since there the user picks the destination.
• The token is stored only after the connection is proven. It was written to SecretStorage
  before connecting, so a failed pairing destroyed a working credential.

Both are consequences of the surrounding multi-candidate connection logic rather than anything wrong
with the feature — the pairing flow itself is unchanged.

If you want to send more our way, fork/dev is the branch to target now. Appreciated. 🙏