TT-7583 fix: only warn of a network issue when the upload never completed

[nabalone]

Follow-up to the TT-7583 auto-save work. The reported bug is that PBT auto-save shows
"Save Failed. Please check your internet connection and try again" when the connection is
fine. This PR fixes the half of that which is about misattributing failures to the network.

The problem

A failed upload item told its callback nothing but success: false. Both itemComplete
handlers (crud/useMediaUpload.ts, components/Uploader.tsx) therefore responded to every
failure by calling setOrbitRetries, which raises the "possible network issue" retry banner
from Sources.tsx — including for a file we rejected locally or a 4xx the server deliberately
returned. The message blamed the user's connection for things that had nothing to do with it.

The change

UploadFailureReason (string enum, store/upload/uploadRetry.ts) names why an item failed:

reason	when	connection problem?
UnsupportedType / TooBig / LocalWriteFailed	never left the client	no
Rejected	server answered 4xx (incl. 429)	no
ServerError	server answered 5xx	no
Timeout	request sent, timed out	yes
NoResponse	never reached the server	yes

suggestsConnectionProblem() is the single place that decides, and both itemCompletes now
call it instead of duplicating the judgment.

Behavior narrows: 5xx and 429 no longer raise the connection warning — both mean we reached
the server. Retry policy is untouched: isRetryableUploadStatus still governs the retry loop
and is now a separate question from "is the user's connection bad".

Why a reason code rather than a bool or a status number

Two alternatives were considered and rejected:

• Tri-state success (ok | retryable | terminal). Real appeal — it removes the redundant
  success: false + failure-object encoding. Rejected because a string union is truthy, so any
  missed if (success) (there is one at useMediaUpload.ts) would silently start reporting
  success; because "terminal failure" already means something different and specific in this file
  (onTerminalFailure = PUT exhausted, row deleted, file queued for later retry); and because it
  can't carry statusNum.
• Pass the HTTP status, derive retryability at each call site. Right instinct, fatal detail:
  isRetryableUploadStatus(undefined) returns true (at the retry layer "no status" means "no
  response"), and local rejections have no status at all — so an unsupported file type would
  compute as a network problem, which is the exact bug being fixed.

The second commit is the interesting one

uploadFile's onerror coerced a dropped connection into a fake 500 (httpStatus || 500;
httpStatus is 0 when the browser never got a response). So a genuine connection drop on the
S3 PUT classified as ServerError and stayed silent — the one case the warning exists for.
The signal was being destroyed a layer below where the classifier read it, so the unit tests on
the classifier could not have caught it. Found by building the fake-error harness, not by review.

actions.failureReason.test.ts now drives real XMLHttpRequest/Axios stubs end-to-end and
asserts the reason that actually reaches cb for all seven paths.

⚠️ Before marking ready

• Revert 6ecd5a1c (TT-7583 TEMPORARY: localStorage-driven fake upload failures). It is
  isolated in one commit precisely so this is a single operation. It adds
  store/upload/fakeUploadFailure.ts plus three blocks in actions.tsx marked
  TEMPORARY (TT-7583 manual test).
• This branch does not rebase cleanly onto develop. git rebase origin/develop conflicts in
  crud/useWavesurferRegions.tsx, between a57c1342 (auto-segment guard, inherited from the
  part2 branch — not from this PR's work) and a5ca8ff5 (TT-7377, "don't reload blob when
  editing"). Left unresolved deliberately: it's a judgment call about the auto-segment feature.
• This branch carries unmerged part2 commits (bc7d3b8e + its revert ba9802da,
  0b107780, a57c1342). If part2 lands separately, rebase to drop them.

Manual test plan

Not yet run against the app — verified by unit/integration tests only. With the harness commit
still present, from the browser console (no reload needed):

localStorage.apmFakeUpload = 'put:0'     // PUT never reaches S3   -> NoResponse   banner
localStorage.apmFakeUpload = 'put:408'   // PUT times out          -> Timeout      banner
localStorage.apmFakeUpload = 'put:403'   // S3 refuses             -> Rejected     silent
localStorage.apmFakeUpload = 'put:500'   // S3 fails               -> ServerError  silent
localStorage.apmFakeUpload = 'post:0'    // POST gets no response  -> NoResponse   banner
localStorage.apmFakeUpload = 'post:403'  // API refuses            -> Rejected     silent
localStorage.apmFakeUpload = 'post:500'  // API fails              -> ServerError  silent
delete localStorage.apmFakeUpload

Record and save a clause on Careful Speech or PBT for each. Two things to watch:

1. The banner appears for exactly the three banner rows and nothing else.
2. Everything else is identical across all seven — save-failed snackbar, file landing in the
   pending-uploads queue, retry loop stopping. If anything beyond the banner changes with the
   reason, that's a bug in this change.

The highest-value single check is put:0 vs put:500 back to back — that pair is exactly the
distinction the fix turns on, and put:0 is the case commit 2 repairs.

Two cases need no harness and exercise the sendError path instead of the network path: upload
a file with an extension outside .wav/.mp3/.m4a/.ogg/.webm/.pdf/.png/.jpg (UnsupportedType),
and one over the size limit (TooBig). Neither should raise the banner.

Noticed, not addressed

The PUT retry loop (actions.tsx) runs all 5 attempts even for a 403, unlike the POST loop which
bails on non-retryable statuses. Visible as a ~6s delay on put:403. Pre-existing; out of scope.

Verification

npm run typecheck:web, ESLint on changed files, and Prettier are clean; the 6 affected Jest
suites (58 tests) passed at the time the work was done. Per request, no CI/Devin checks were run
or waited on for this PR.

🤖 Generated with Claude Code