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.