Windows: installer does not register buzz:// and cold-start deep links are dropped

## Summary

The official `v0.4.24` Windows NSIS installer does not register the configured `buzz://` protocol, and launching the installed executable with a `buzz://nostr-bind?...` argument on a cold start does not deliver the request to the app. This blocks the shipped Nostr identity proof flow on Windows.

The same source shape remains on `v0.4.25`, `v0.4.26`, and current `main`.

## Reproduction

Environment: Windows x64, official `Buzz_0.4.24_x64-setup_alpha-unsigned.exe` from the GitHub release.

Verified installer SHA-256:

```
1931fff983f612364860f723997cd3692083a7128fe3b82c18f55d0144442c78
```

1. Install through Windows Explorer into the normal per-user location.
2. Launch Buzz, create/import an identity, close it completely, and reopen it. Identity persistence succeeds.
3. Inspect protocol registration:
- `HKCR\buzz` is absent.
- `HKCU\Software\Classes\buzz` is absent.
4. Open a valid `buzz://nostr-bind?...&return=clipboard` URL from Chrome. No signing dialog appears.
5. Pass the same valid URL as the sole argument to the installed `buzz-desktop.exe`. On cold start the app remains on “Join or create a community”; no signing dialog appears.

The request itself is accepted by `parse_nostr_bind_deep_link` in source/unit fixtures and has valid challenge, nonce, six-digit code, protocol/action/audience/version, HTTPS origin, RFC3339 expiry, and clipboard return mode.

## Source diagnosis

`tauri.conf.json` correctly declares:

```json
"deep-link": { "desktop": { "schemes": ["buzz"] } }
```

However, `tauri-plugin-deep-link` 2.4.9 does not register configured Windows schemes merely from `init()`. Its documented `DeepLinkExt::register_all()` writes `HKCU\Software\Classes\`, but Buzz never calls it.

There is also a cold-start delivery race:

- plugin initialization calls `handle_cli_arguments(std::env::args())`, stores the URL in `current`, and emits `deep-link://new-url`;
- Buzz attaches `on_open_url` later inside the application `.setup(...)` callback;
- Buzz does not consume `app.deep_link().get_current()` after attaching the listener;
- the single-instance callback covers a later duplicate process, but not the first process's already-emitted cold-start event.

Relevant code is in `desktop/src-tauri/src/lib.rs` around the deep-link plugin registration and the `on_open_url` setup block.

## Expected correction

On Windows/Linux startup:

1. Call `app.deep_link().register_all()` (with explicit nonfatal/error behavior appropriate for release startup) so official installs and portable launches self-repair protocol registration.
2. Attach the `on_open_url` handler.
3. Immediately consume `app.deep_link().get_current()` and route each URL through the same `handle_deep_link_url` function, deduplicating if necessary.
4. Preserve the existing single-instance forwarding for an already-running app.

Please add Windows-focused coverage for:

- configured protocol registration;
- cold launch with exactly one `buzz://nostr-bind` argument;
- already-running second-instance forwarding;
- no duplicate prompt/event when startup/current and runtime delivery overlap.

## Security note

A manual registry edit can diagnose the running-instance path, but it is not a distributable product fallback. The identity private key must remain in Buzz Desktop; browser-side or server-side signing is not an acceptable workaround.

Read desktop/src-tauri/src/lib.rs around deep-link plugin registration, the on_open_url setup block, and handle_deep_link_url; compare the startup flow with tauri-plugin-deep-link's register_all() and get_current() behavior. Done means Windows/Linux startup registers the buzz scheme, delivers one cold-start URL, preserves already-running forwarding, and has Windows-focused coverage without duplicate prompts or events.

Written by the indexing model from the issue text.