fix(feedback): stop send-logs hanging forever in sending state

[Anshgrover23]

Description:

Fixes #5360

Before: clicking "send logs & feedback" could freeze the dialog on SENDING… forever — button disabled, no error, no retry. None of the calls in sendLogs had a timeout, so one stalled connection (or one hung Tauri command) left the promise pending permanently and the catch that resets the UI never ran. On top of that, the exact scenario users report from ("recording needs help" → recorder spamming errors into the log) balloons the log file to hundreds of MB, and readTextFile pulled the entire file across IPC just to keep the last 100 KB — freezing the dialog even on a perfect network.

After: every network/IPC step has a deadline; when one is exceeded the existing error path runs — the button returns to idle with a clear "timed out — check your connection and try again" toast, and the user can retry. Log files are tail-read in Rust (seek to end, read only the last 100 KB), so a runaway log can no longer freeze the report flow. What support receives is unchanged — the report always contained only the last 100 KB per log file.

BEFORE                                     AFTER
──────                                     ─────
[ ⣟ SENDING… ]  (forever, no way out)      [ ⣟ SENDING… ]
      │                                          │  step exceeds its deadline
      ▼                                          ▼
   (nothing — button disabled,             toast: "sharing failed —
    user force-quits the app)               upload request timed out…"
                                           [ SEND LOGS & FEEDBACK ]  ← enabled, retry works

• share-logs-button.tsx: add fetchWithTimeout (AbortController) and withTimeout (promise race); apply to the signed-URL request (30s), redaction (60s — Rust self-bounds at 45s), log/screenshot PUTs (60s), video upload (5 min), and confirm (30s); add xhr.timeout/ontimeout to putWithProgress; check signedRes.ok before parsing so a server error surfaces as a readable message
• media_commands.rs: upload_file_to_s3 used a reqwest client with no timeout, so a stalled PUT hung attempt 1 forever and the 3-retry loop never advanced — now 10s connect / 90s per attempt (3 × 90s + backoff fits inside the webview's 5-min deadline, so all retries get to run)
• log_files.rs: new read_log_tail command — seek to len - max_bytes and read only the tail, same truncation banner as before; sendLogs uses it instead of readTextFile + slice
• timeouts are ceilings (~10× the worst realistic duration per step), so the happy path is behaviorally unchanged; the only trade is that an upload genuinely slower than 5 min now errors with retry instead of (eventually) succeeding
• tests: Rust — read_tail returns small files whole, truncates large files to exactly the tail with banner, errors on missing files (8/8 pass); vitest — regression test that a hung request recovers to idle with a timeout toast after 30s instead of sticking on SENDING…, logs are read via readLogTail, and withTimeout unit tests (22/22 pass)

[github-actions]

👋 thanks for the pr!

i couldn't find a before/after screen recording in the description. prs without a video showing the change in action are hard to review and may be closed soon as potential ai slop.

to clear this:

• add a short screen recording of the app/cli before and after your change to the pr description
• drag the file into the description box — github hosts it (never commit media into the repo)
• the potential-ai-slop label drops automatically once a video is detected

if a video genuinely doesn't apply (docs / ci / pure refactor), reply here and a maintainer can remove the label.

[Anshgrover23]

@louis030195 Can I get a review on this one ?

[louis030195]

Code review: not ready to merge yet.

1. getLogFiles() is still unbounded. Because that Tauri command walks the configured data directories, a stalled filesystem or IPC call still leaves the UI in SENDING... forever—the exact bug this PR is intended to eliminate. Please add an end-to-end deadline around the send operation (or at minimum this call) and a regression test where getLogFiles never settles.

2. The 90-second reqwest timeout is a total per-attempt timeout, not a stall timeout. A slow but progressing recording upload that needs 91–300 seconds is killed and restarted three times, then fails even though the UI allows five minutes. Give one attempt most of the outer budget, make the timeout size-aware, or detect lack of progress instead of using a fixed 90-second total.

[Anshgrover23]

@louis030195 Addressed both comments, Can I get a review on this one ?