# Test — Upload 500 MB Cap

**Task**: AZ-476_test_upload_size_cap
**Name**: Upload >500 MB → 413 + user-visible error (no alert)
**Description**: Implement the 2 blackbox tests pinning the upload size cap behavior (per E9 / AC-10): nginx-side 413 on a 501 MB file is surfaced to the user via a friendly in-DOM error — never `alert()`.
**Complexity**: 2 points
**Dependencies**: AZ-456_test_infrastructure
**Component**: 06_annotations (upload) (Blackbox Tests)
**Tracker**: AZ-476
**Epic**: AZ-455

## Problem

A 413 hidden behind a `console.error` makes the SPA look unresponsive. The contract: when nginx rejects an oversized upload, the SPA shows an i18n-keyed error in the DOM, without `alert()`.

## Outcome

- 2 scenarios pass.

## Scope

### Included

| Scenario | Profile | Source file |
|----------|---------|-------------|
| FT-N-06 — upload of 501 MB file surfaces a user-visible 413 error | fast + e2e | blackbox-tests.md |
| NFT-RES-07 — nginx 413 on oversized upload surfaces user-visible error | fast + e2e | resilience-tests.md |

### Excluded

- Upload success path (out of scope for the baseline).
- Multi-part chunked uploads (not supported — out of scope).

## Acceptance Criteria

**AC-1: User-visible error**
FT-N-06 / NFT-RES-07 — attempt to upload a 501 MB file; nginx returns 413; the SPA renders a user-visible in-DOM error (toast or inline) carrying the i18n-keyed message.

**AC-2: No alert**
The error path does NOT invoke `alert()` (defence in depth — caught by NFT-SEC-07 as well, but asserted here too).

## System Under Test Boundary

- System under test: upload flow component(s) + `src/api/client.ts` upload helper.
- Allowed stubs: in `fast`, MSW responds 413; in `e2e`, the suite's real nginx enforces the cap.
- Disallowed: stubbing the upload component.
- Expected observables per `results_report.md` rows 38-39.

## Constraints

- E2E test sends a 501 MB sparse file (zero-filled) to avoid bloating CI bandwidth.
