Declined/failed desktop login redemption drops the code silently: no cancel signal to Desktop, no telemetry

`src/platform/cloud/onboarding/desktopLoginRedemption.ts` drops the login code silently on every non-success path, and sends nothing back to Desktop. The user's app then hangs on a spinner until the code's 30-minute TTL expires.

## Problem

After signing in, the user gets an approval dialog before the code is redeemed (`confirmRedemption()`). It exists for a good reason: it defeats device-code phishing, where an attacker gets a victim to approve the attacker's login code. That is not in question.

What is in question is what happens when approval is not granted. On decline the handler does `settle(code, state); return` - the state is cleared locally and nothing is sent anywhere. The same is true when the redeem hits a terminal status (`TERMINAL_REDEEM_STATUSES` = 400, 403, 404, 409, 410) and when the user simply closes the tab.

From the user's point of view: they signed in, the browser looks finished, and the desktop app sits on a spinner for half an hour before reporting a generic failure.

There is also **zero telemetry anywhere in this file**, so we cannot currently size how often each of these paths is taken.

## Evidence this is a real population

Of everyone who starts a Desktop sign-in, 16% end up signed in on the web while Desktop never receives it - roughly 440 people a day. Those people authenticated successfully and our software failed to close the loop. Before 8 August that bucket was 6-7%, so it more than tripled, but it was never zero.

Separately, 93% of all Desktop login-code failures fire in a 25-33 minute band, i.e. at the TTL rather than at the moment anything actually goes wrong. Some unknown share of those are this path.

## Asks

1. Send a cancel signal back to Desktop when the approval is declined, so the app can fail fast and show something actionable instead of waiting out the TTL. This needs a decline endpoint or an equivalent, since there is currently no channel from browser back to Desktop other than redemption itself.
2. Instrument the file. At minimum: approval shown, approved, declined, redeem attempted, redeem terminal-failed with status. Without these we are guessing at the size of every branch.
3. Consider whether a terminal 4xx on redeem should surface an error to the user in the browser, rather than silently settling.

## Related

- Comfy-Org/Comfy-Desktop#1358, Comfy-Org/ComfyUI_frontend#14457 (handoff observability)