RV-F10 (BR-25): failed uploads unreachable through normal browser review flow #187

What happened

External repo review at commit c7bebd1: review links are built only from successful migrated-file entries; all-failed dynamic uploads have no such entry. Frontend upload-response schema drops the returned uploadId.

Code paths:

• csv-table-hub-main/src/routes/_authenticated/index.tsx L682–702 (review links from migrated files)
• csv-table-hub-main/src/lib/csv.functions.ts L39–82 (upload-response schema drops uploadId)

Note: touches csv-table-hub-main/* (Lovable frontend code), partially blocked by #154.

Why this matters

BR-25 promises access to every uploaded row. API already preserves failed uploads (M4a scope, #142). User has no normal navigation path to reach them from the browser. A reviewer investigating "why did this upload fail?" has no UI to find it.

Also interacts with #170 (RV-F3 all-failed T&E cleanup): after that fix, more failed uploads are preserved. If the UI can't reach them, the fix delivers less value.

Proposed

1. Build the browser queue from the upload-attempt registry (which already includes failed), not from the migrated-file entries.
2. Frontend upload-response schema retains uploadId on every outcome (success, partial, all-failed).
3. Add a filter or badge for "failed/partial" uploads in the review screen.
4. Covered by the Spike: rebuild M4 review screen in Streamlit (1-day time-box) #154 decision for actual implementation (if Lovable retained, patch; if replaced, part of the replacement scope).

Done when

• All-failed upload appears in the review browser with a review link.
• Clicking the link opens the review screen showing the row-level validation errors from M4a.
• vitest coverage for the response-schema change and the browser-queue source.

Reference

Tracker row G53. Repo review finding RV-F10. BR-25. Depends on #154 decision for frontend implementation.