desktop: gate instant uploads with a cached health probe

[Peter7896]

/claim #73

This keeps the upload-speed and upload-health logic on one bounded path for Instant mode instead of doing a real object upload in the middle of the recording flow.

What changed:

• add a desktop upload-health probe with a bounded payload, short timeout, and a 10 minute cache
• use the cached result to cap Instant recording resolution before recording starts
• add a web upload-health route that measures uploadability without leaving probe objects behind in storage
• surface the health state in the desktop UI and add focused desktop/web coverage around tiering and byte limits

Follow-up hardening:

• validate the server-reported receivedBytes before calculating throughput
• subtract a same-route HEAD round trip estimate from the POST timing when it is safe to do so, reducing high-latency underestimation
• short-circuit overlapping refresh probes so concurrent startup, interval, manual, or post-recording checks do not race the cache
• avoid clearing the refresh spinner from non-refresh status reads
• make the Content-Length check an explicit fast path while keeping stream-side byte counting as the enforcement boundary

Why this shape:

• recording start only consumes cached state, so we do not wait on a fresh speed check after the user has already started recording
• the health route exercises the upload path without introducing orphaned probe files or cleanup requirements
• resolution gating stays conservative and only narrows Instant mode when the measured path says uploads are weak
• the RTT adjustment avoids punishing high-latency links when actual upload throughput is still healthy

Validation:

• git diff --check
• pnpm exec biome check on touched TypeScript files
• pnpm --dir apps/desktop exec vitest run src/utils/upload-health.test.ts
• pnpm --dir apps/web exec vitest run tests/unit/desktop-upload-health.test.ts
• cargo fmt --manifest-path apps/desktop/src-tauri/Cargo.toml --check
• cargo test -j 1 -p cap-desktop upload_health --lib

[superagent-security]

Superagent didn't find any vulnerabilities or security issues in this PR.

[Peter7896]

Rebased this branch onto current main in 4d6c849 and resolved the merge conflict in apps/desktop/src/routes/(window-chrome)/new-main/index.tsx by keeping the upstream updater import together with the upload-health imports. The PR diff remains scoped to the desktop upload health probe path.

Validation:

• pnpm --dir apps/desktop exec vitest run src/utils/upload-health.test.ts -> 6 passed
• pnpm --dir apps/web exec vitest run __tests__/unit/desktop-upload-health.test.ts -> 3 passed
• pnpm exec biome check apps/desktop/src/routes/(window-chrome)/new-main/index.tsx apps/desktop/src/utils/upload-health.ts apps/desktop/src/utils/upload-health.test.ts apps/web/__tests__/unit/desktop-upload-health.test.ts apps/web/app/api/desktop/[...route]/root.ts apps/web/app/api/desktop/[...route]/uploadHealth.ts
• git diff --check origin/main...HEAD

cargo check -p cap-desktop is still blocked in this local Windows environment before checking this crate because the FFmpeg headers are not installed (libavutil/avutil.h missing in ffmpeg-sys-next).