fix(auth): Route treq://auth/callback deep links on desktop

[Ziinc]

• The desktop handler only routed agent links, so browser sign-in never completed. treq://auth/callback links now go to one window as deep-link-received. One window only, because the token can be exchanged once
• Add tauri-plugin-single-instance (deep-link feature, registered first) so on Windows and Linux the link reaches the running app and focuses it. Trade-off: a dev build and an installed Treq (both com.treq) can no longer run at the same time
• Unit tests cover routing and the token exchange. Real sign-in and OS link delivery were not tested; manual steps are in a comment
  Fixes TREQ-319
  🤖 Generated with Claude Code
  https://claude.ai/code/session_01V9MDdxQJAhjXsAKyCpVwwt
  Generated by Claude Code

[Ziinc]

Manual test steps

None of these were run. The environment that built this PR had no desktop session, no OAuth provider and no OS URL handler, so a real sign-in and real OS deep-link delivery are untested. The unit tests only cover routing (classify_deep_link) and the frontend exchange (AppStoreEffects.test.tsx).

Use a release build (npm run tauri build), installed. Treq should be running and signed out.

macOS

1. Settings → Account → Sign in with Browser, then finish sign-in in the browser and allow "Open Treq?".
2. Expected: Treq comes to the front, the Account page shows your email, and there is no "deep link ignored" line in the log.
3. Open Treq again with open -a Treq. Expected: the running window comes to the front and no second instance starts.

Windows (installer build)

1. Do the same sign-in flow. Expected: you end up signed in, the existing window comes to the front, and Task Manager shows one Treq process.
2. With Treq running, run start "" "treq://auth/callback?token=bogus". Expected: the existing window comes to the front and no second process starts (the bogus token fails to exchange, without an error).
3. Launch Treq again from the Start menu. Expected: the existing window comes to the front.

Linux (.deb and AppImage)

1. For the AppImage, launch it once. Expected: xdg-mime query default x-scheme-handler/treq prints treq-handler.desktop.
2. Do the sign-in flow. Expected: you end up signed in, the window comes to the front, and pgrep -xc treq prints 1.
3. With Treq running, run xdg-open 'treq://auth/callback?token=bogus'. Expected: the same window comes to the front and no new process starts.

Regressions (all platforms)

• With a repo open, dispatching an agent through a treq://agent/start?... link still starts the agent in that repo's window.
• Running treq <subcommand> from the CLI still works while the app is open, because CLI calls exit before any plugin loads.

Known gaps and trade-offs

• If Treq is not running when the callback link opens, the link that launches it is not routed. You have to click Sign in again.
• With several windows open, the token goes to the focused or last-focused window, not necessarily the one where Sign in was clicked.
• A dev build (npm start) started while the installed Treq is running now exits and brings the installed app to the front, because both use the identifier com.treq.
• Linux (every build) and Windows dev builds register treq:// at startup. On Linux, whichever build started last owns the handler. On Windows, after running a dev build, the dev exe stays the handler until you reinstall.

---

Generated by Claude Code