Declare the desktop app as the preferred bridge channel

[philipp-winterle]

UI half of a two-part change. Server half:
httptoolkit/httptoolkit-server#246

That one carries the tests and the full write-up; this side is the sender.
It is safe to merge in either order - until the server side lands, priority
is simply an extra field nobody reads.

The problem

The server's UI operation bridge picks whichever UI connected first as the
channel that answers every MCP and CTL operation, and whose account decides
isPaidUser(). With the desktop app and a browser tab both pointed at the same
server, which one wins comes down to startup order, and the user has no way to
steer it.

The change

The bridge accepts an optional priority in the operations message
(httptoolkit/httptoolkit-server#246). The desktop shell sends 1, a browser tab
sends 0, so the app the user is actually driving takes the role whatever the
connection order was.

isDesktopShell() reads the injected desktop API directly because it has to
answer synchronously here. desktopVersion can't be used for this - by its own
comment it never resolves in a browser, so it cannot tell the two apart.

Test plan

• tsc --noEmit reports nothing in either changed file. (The repo has
  pre-existing type errors elsewhere under a bare tsc, so this is scoped to
  the diff.)
• No unit test added: server-operation-bridge.ts has no test file today and
  no seam to reach the socket through, and the behaviour this field drives is
  covered by the server-side PR's tests. Glad to add one if you can point me
  at the shape you'd want.
• Not exercised against a running desktop build - I don't have the packaged
  shell set up, only the local web UI, where isDesktopShell() correctly
  reports false.

[CLAassistant]

All committers have signed the CLA.

[pimterry]

@philipp-winterle, I'm going to close this and httptoolkit/httptoolkit-server#246 I'm afraid. It's an interesting idea, but I think it adds complexity for a pretty niche scenario (running both the desktop app and the UI independently on the same machine) and I'm not sure the result is correct anyway - if you're using the UI, it's totally possible that you want the MCP to control it instead of the desktop app. If anything the UI is the case that's more convenient for automation scenarios. The "first session wins" model is simpler and clearer imo.

[philipp-winterle]

Got it. Iam using the app without the ui and the mcp to be controlled and read by an python app. The UI was the human interface I was going to read. But they had some issues being connected to the same websocket.

Iam fine if do not want to add this. I have a patch file for this use case.