Silent fallback to the legacy loopback bridge is untelemetered and fails 3x more often

`handleFirebasePopup` calls `signInViaDesktopLoginCode` first, and on a `'fallback'` return (code creation failed before the browser opened) transparently degrades to the legacy loopback bridge on port 9876. Nothing is emitted at the point of that decision, and the user is not told they are on a different, worse flow.

## Evidence

Last 7 days, by flow and version:

| Flow | Version | Attempts | Failed | Rate |
|---|---|---|---|---|
| `desktop_login_code` | 1.0.39 | 7,095 | 719 | 10.1% |
| `desktop_login_code` | 1.0.38 | 26,039 | 2,639 | 10.1% |
| `loopback_bridge` | 1.0.39 | 90 | 29 | **32.2%** |
| `loopback_bridge` | 1.0.38 | 548 | 176 | **32.1%** |
| `loopback_bridge` | 1.0.37 | 63 | 25 | **39.7%** |

So the legacy path is still live on current shipping builds and fails about three times as often as the code flow. It is roughly 2% of volume, so this is not the main event, but it is a known-bad path that we silently route people onto.

## What is missing

There is no telemetry on the fallback decision itself. We only know it is happening at all by inferring it from the `flow` property on the events that follow. That means we cannot answer:

- how often code creation fails before the browser opens (the trigger condition)
- why it fails - `CREATE_CODE_TIMEOUT_MS` is 8s, so a slow network and a hard error look identical downstream
- whether the fallback then succeeds more or less often than a clean retry of the code flow would have

## Asks

1. Emit an event at the fallback decision point, with the reason code creation failed and whether it was a timeout or an error status.
2. Decide whether the fallback should still exist. It was a transitional safety net for the login-code rollout; that rollout is now complete and the fallback is measurably worse than the thing it protects against. A bounded retry of code creation may beat degrading to a 32%-failure path.
3. If it stays, consider surfacing it. A user on the loopback bridge is three times more likely to fail and has no idea they are on a different flow.

## Context

The login-code rework itself was a clear win and this ticket is not an argument against it. Event-level failure ran 26-30% on the loopback bridge through late July, fell to 12.8% when the code flow shipped in v1.0.31, and to ~6% once the follow-ups landed on 31 July. This is about the residue that still routes to the old path.