desktop/src-tauri/src/lib.rs is at the file-size ratchet cap, so registering any new Tauri command fails desktop-check

## Summary

`desktop/src-tauri/src/lib.rs` sits at **exactly** the desktop file-size ratchet cap, so any PR that registers a new Tauri command fails `desktop-check` — and the error names the wrong cause.

At the time of writing (`978e585e8`) the file is 1000 lines by the ratchet's own counting, and `MAX_LINES` is 1000:

```
Desktop file size ratchet failed (base 978e585e8):
- src-tauri/src/lib.rs: 1000 -> 1001 (+1) lines (allowed 1000)
Keep new files at or below the limit; files already over it may not grow.
```

Registering a command costs exactly one line in the `tauri::generate_handler![…]` list, so **the minimum possible change is already over budget**. There is no way to add a command without an unrelated refactor first.

## Why this is worth fixing rather than absorbing

The failure is misdirecting. A contributor adding one line to a handler list gets told their file is too large, in a file they only touched incidentally. Nothing points at the real situation: a shared registration surface has run out of room, and clearing it requires moving unrelated code out of `run()`.

It also lands on exactly the contributors least equipped to diagnose it — someone's first command registration fails a check that has nothing to do with their change.

## What doesn't work

Extracting the `generate_handler![…]` list itself into its own module is the obvious fix and it **is not viable**: `#[tauri::command]` generates hidden `__cmd__*` / `__tauri_command_name_*` macros that must be in textual scope at the `generate_handler!` call site. Glob imports do not carry them, so the list only moves if all ~276 entries are path-qualified. I tried it; it fails with ~550 `cannot find macro __cmd__…` errors.

## Interim mitigation (already up)

#4715 moves the push-to-talk global-shortcut plugin (86 self-contained lines) out of `run()` and into the existing `ptt_shortcut` module, taking `lib.rs` to 915 lines. Behaviour-neutral, kept as its own commit, full desktop gate green.

That buys ~85 lines of headroom. It is a reprieve, not a fix — the file grows again and the next contributor hits the same wall with the same misleading message.

## Possible durable fixes

1. **Split `run()`.** It is ~910 of the file's 1000 lines: plugin registration, the `.setup` closure, and `RunEvent` handling are all separable. This is the honest fix and would leave real room.
2. **Exempt the handler list from the line count.** The ratchet counts a flat registration list the same as logic, but a 300-line list of command names is not the complexity the rule exists to prevent. Skipping lines between `generate_handler![` and its closing `]` would make the cap measure what it means to measure.
3. **Fail with a better message** when a file is *at* the cap rather than over it — something naming the structural cause instead of the symptom.

(1) and (2) are complementary; (2) alone would unblock command registration permanently and is the smaller change.

Happy to do whichever you prefer — I have the environment set up and can verify against the full desktop gate.

Start with desktop/src-tauri/src/lib.rs and the file-size ratchet configuration containing MAX_LINES, then run the desktop-check gate to reproduce the failure when the handler list grows. Compare the proposed run() split and handler-list exemption, using the constraints around generate_handler! as a guide. Done means new command registration no longer fails at the cap and the full desktop gate remains green.

Written by the indexing model from the issue text.