feat(app): pair servers from QR codes

[Hona]

Issue for this PR

Requested QR pairing for the V2 web and desktop clients. No linked issue.

Type of change

• Bug fix
• New feature
• Refactor / code improvement
• Documentation

What does this PR do?

Adds QR pairing to Add Server using the existing opencode2 pair payload. Browser users can scan with a camera; web and desktop users can import a QR image. The dialog explains which command to run.

• Validates and fills the address and credentials, then uses the existing authenticated connection check when the user selects Add server. Scanning does not send credentials to the advertised addresses.
• Uses native URL parsing and ipaddr.js range/CIDR APIs to prefer public addresses, then tailnet, LAN, link-local, and loopback. HTTPS breaks ties. Alternatives remain selectable; this is address preference, not a reachability probe.
• Keeps camera resources scoped to the scanner and the dialog usable on short screens. No CLI package changes.

The QR format is unchanged and contains the reusable service password. Remote connections still require a reachable listener; browsers may block HTTP servers from an HTTPS page. This PR does not add TLS or change server binding.

How did you verify your code works?

• App unit suite: 609 passed. Browser-condition suite: 69 passed.
• App, desktop, and CLI bun typecheck; production web build.
• Three Playwright pairing tests against the production build: real QR-image decoding/authentication, invalid codes, and camera cleanup with a canvas-backed MediaStream at 390x600.
• Desktop/mobile, English LTR/RTL, and Arabic RTL visual checks. Scanner decoding is lazy-loaded.
• Prettier and git diff --check.

Full typecheck:e2e is blocked by the existing HTMLElement | SVGElement.dir error at e2e/regression/new-session-workspace-pending.spec.ts:38, also present in the base commit. Physical camera hardware was not used.

Screenshots / recordings

Before:

After:

Mobile:

RTL:

Checklist

• I have tested my changes locally
• I have not included unrelated changes in this PR

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

[AhsanIqbal-web]

Hi @Hona — this is a great foundation for the pairing flow. I'd like to build the complementary serve-side generation: a --qr option for opencode serve that emits a terminal-rendered QR encoding exactly this PairingInfo shape (same JSON schema, same scope-ordered urls), resolves candidate addresses from the machine's network interfaces (loopback / LAN / tailscale if present), and ensures a password exists (generating an ephemeral one via OPENCODE_SERVER_PASSWORD-compatible flow when unset, printing it alongside the QR for terminal users).

That would complete the loop with your scan-side parser without touching any files in packages/app/ — my changes would live only in packages/opencode/src/cli/ (serve.ts, network.ts + a small pairing-qr module). Zero file overlap with this PR.

Two questions before I start:

1. Is the PairingInfo JSON shape here considered stable enough to code against from the server side, or do you expect it to change while this PR evolves?
2. Should serve-side QR generation also advertise a ts.net hostname when Tailscale is detected, or keep to interface-derived addresses only?

Happy to coordinate on payload details — the goal is that a QR generated by serve --qr pairs cleanly with this dialog on first scan.