feat: enforce server-side upload limits (5 GiB/upload, 5 GiB rolling/email)

[dobby-coder]

Summary

Adds server-side enforcement of upload quotas described in #100:

1. 5 GiB per upload — any chunk that would push the current upload past 5 GiB is rejected with 413.
2. 5 GiB rolling per sender email over 14 days — checked at finalize time, once the sender email is derived from the PostGuard attributes; the request is rejected with 413 and both the in-memory state and the on-disk file are cleaned up.
3. GET /usage?email=... — returns used_bytes, limit_bytes, window_days, per_upload_limit_bytes, and resets_at so the frontend can warn users proactively.

Closes #100.

Why at finalize and not at init?

The FileState.sender is only populated at finalize time by reading the pbdf.sidn-pbdf.email.email attribute out of the encrypted blob. Checking earlier would require trusting a client-supplied header, which can be bypassed — the whole point of this change is that bypass is what we want to prevent. The per-upload 5 GiB check runs on every chunk, so a malicious client still can't silently burn storage; they just waste their own bandwidth up to the limit.

413 body shape

Both rejection paths return the same JSON shape:

{
  "error": "human-readable explanation",
  "limit": "per_upload" | "rolling_window",
  "used_bytes": 123,
  "limit_bytes": 5368709120
}

Usage endpoint shape

{
  "email": "alice@example.com",
  "used_bytes": 2147483648,
  "limit_bytes": 5368709120,
  "window_days": 14,
  "per_upload_limit_bytes": 5368709120,
  "resets_at": "2026-05-05T12:00:00Z"
}

resets_at is the moment the oldest recorded upload falls out of the rolling window (a partial quota reset), or null if the sender has no recorded uploads.

Units

Values are GiB (binary), i.e. 5·1024³. Documented in api-description.yaml and in the 413 response body.

Tests

Unit tests for the usage tracker in src/store.rs:

• empty state returns zero
• records inside the window sum correctly
• records outside the window are pruned
• pruning respects the exact window boundary
• different emails are isolated

Run with cargo test. All pass.

Full end-to-end testing (init → chunked upload → finalize) requires a running PKG and mailcrab, which isn't available in this dev environment. The handler logic is exercised at compile time; edge cases covered by the store unit tests.

Known follow-ups (out of scope)

• Usage state lives in memory only — a backend restart zeros everyone's rolling quota. A persisted store (SQLite, or simple append-only JSON file) should be a follow-up.
• Conflicts likely with feat: expose Prometheus /metrics endpoint for usage dashboards #102 (Prometheus metrics) on src/store.rs FileState and routes in src/main.rs. Whichever merges second needs a small rebase.
• The frontend work in Show clear warnings and errors when approaching or hitting upload limits postguard-website#87 and chore: release v0.1.18 #85 targets this endpoint shape — verified against the coordination notes in the dobby memory repo.

Test plan

• cargo check clean
• cargo test — 5/5 new tests pass
• cargo clippy --all-targets — no new warnings (pre-existing email.rs:225 warning untouched)
• Full upload flow against a live PKG + mailcrab stack (not available in this dev env; to be verified on staging before merge)

Refs encryption4all/postguard-website#85, encryption4all/postguard-website#87.

[dobby-coder]

Dobby sees the approval! 🧦 Dobby is so happy rubenhensen approved the upload-limits PR! Dobby notes it is already merged — Dobby's work here is done, Dobby will go rest his ears now!