Crash-report send prompt for local minidump + app.log bundle (too large for telemetry channel)

### Problem

PR #1198 (issue #1108) now produces durable crash artifacts on disk:

- a rotating global `app.log` (main-process console, uncaught errors, process-gone reasons, operation output), and
- native Crashpad minidumps in `app.getPath('crashDumps')` for GPU / renderer / native / OOM crashes that never throw a JS error.

But there is **no user-facing way to actually send these after a crash**. `crashReporter` is started with `uploadToServer: false` (local only), and these artifacts are too large for the existing telemetry channel — a single minidump is ~1–5 MB (plus the `app.log`), well beyond PostHog's ~1 MB per-event limit and not something we can quietly auto-submit. So today the only path is "ask the user to manually zip and email the folders," which won't happen in practice.

### Proposal

On the **next launch after a crash** (detect a new minidump in `crashDumps/` whose mtime is newer than the last clean shutdown), show a per-incident opt-in modal:

- **Title:** "ComfyUI Desktop closed unexpectedly"
- **Body:** "Would you like to send a crash report so we can fix this? It includes a diagnostic log and a crash dump (a few MB). Sensitive data is removed before sending."
- **Buttons:** "Send report" / "Not now"

If the user accepts:

- Bundle the relevant minidump(s) + the last N lines / current `app.log` into a single package.
- Upload to a crash-collection endpoint sized for multi-MB payloads (NOT the PostHog event channel). Options: wire `crashReporter`'s `submitURL` to a Crashpad-compatible collector, or a dedicated upload to a service that symbolicates server-side (Sentry / BugSplat / Backtrace / Datadog crash reporting).
- As a fallback when no uploader is configured or upload fails, offer "Save report…" that writes the bundle to a file the user can attach manually (this is the **exportable diagnostic report** in #376).
- Apply `scrubAll` (`scrubPII` + `scrubSecrets`) to the `app.log` portion before sending; the minidump itself carries no app strings beyond native stacks/modules.
- Delete the dump after a successful send (complements the retention sweep added in #1198).

### Relationships

- **Builds on #1108 / PR #1198** — that work creates the `app.log` + minidumps this flow sends, and added a startup retention sweep so the folder stays bounded.
- **Complements #381** ("Crash report dialog for non-opted-in users") — #381 grants one-time consent to send a *small anonymized Datadog event*. This issue is about the *large minidump + log bundle*, which needs a different (sized) transport and an explicit per-incident choice. The two can share one dialog: the event goes via #381's path, the heavy bundle via this one.
- **Feeds #376** (exportable diagnostic report) — the "Save report…" fallback is exactly that artifact.

### Dependency / open question

A minidump is only useful once **symbolicated**, which requires retaining the build's debug symbols (`.pdb` / `dSYM` / Breakpad `.sym`) per release, plus matching Electron symbols. Before investing in upload, confirm whether the ToDesktop build pipeline retains symbols — that determines whether received dumps are decodable. (Spike worth doing first.)

### Acceptance criteria

- After a crash, the next launch detects the dump and presents a per-incident opt-in modal.
- Accepting sends (or saves) a redacted `app.log` + minidump bundle via a transport that handles multi-MB payloads — not the telemetry event channel.
- Declining sends nothing; choice is per-incident, not a blanket consent change.
- On successful send, the dump is removed.

Start by reviewing PR #1198 and the existing local crashReporter setup, including the crashDumps path and app.log artifacts. First confirm whether the ToDesktop build pipeline retains matching PDB, dSYM, Breakpad, and Electron symbols. Done means a next-launch per-incident prompt can send or save a redacted multi-MB bundle, decline sends nothing, and successful sends remove the dump.

Written by the indexing model from the issue text.