docs: state the PDF resource limit, and bring the PNG one up to date

[FHoffarth]

Documentation only. One file, README.md, +20 / −4. No product code, no test, no fixture.

This is the v0.1 half of the decision in #10 (B) document/accept for v0.1, harden later).
Option 1 there was mandatory rather than optional: a limit nobody states is an unnoticed one,
not an accepted one.

Both changes land in What FilePass refuses to spend, and they are separate things.

---

1. PDF — the limit that was never stated

The section described a PNG ceiling and said nothing about PDFs, which implied a symmetry that
does not exist. FilePass unpacks nothing in a PDF itself: pdf-lib and pdfjs-dist do it while
they parse, and some of it happens before FilePass has seen enough of the file to have an
opinion about it.

The sentence that carries the actual correction:

The 50 MB limit above is a limit on the file as it arrives, not on what it turns into.

That distinction is the part a reader could not previously have worked out. A one megabyte file
whose metadata is compressed around a thousand to one expands to roughly a gigabyte and takes
the better part of a minute.

The paragraph is equally explicit about what the cost is not, because that is what makes
accepting it defensible rather than resigned. Measured in #8 and #10, up to a 1 GiB payload:
the file is still read correctly, the cleaned copy is still verified honestly, the page does not
freeze, the tab does not fall over, and no verdict changes. What it spends is time and memory on
the reader's own device.

2. PNG — bringing an existing claim up to date

The PNG paragraph was accurate when written and quietly stopped being so when the shared budget
landed in #6. It still described one megabyte per chunk and eight megabytes for a whole file,
with no mention of the sixteen megabyte colour-profile ceiling or the shared total that stops
text and profile being added together to claim more than either.

Not new scope: it is the same section, the same subject, and leaving it would have placed a
stale claim directly beside a new honest one. Nothing about the code changes — this describes
what #6 already shipped.

---

Gates

Gate	Result
Product tests	5 files / 43 tests passed
Audit tests	23 files / 316 tests passed
tsc --noEmit	clean
vite build	4.00 s
npm audit --audit-level=high	0 vulnerabilities
git diff --check	clean
git diff audit/	empty — no tracked evidence file touched
git status --porcelain after the commit	empty

Not in this PR

The hardening the decision deferred is tracked in #12, with the concurrency guard and the
cancellation architecture kept as separate workstreams on purpose. No tag, release or deploy
proposed.

🤖 Generated with Claude Code