fix: make PNG stream cleanup best-effort

[FHoffarth]

Closes #7.

The rule this enforces

A failed cleanup must never replace the original fail-closed error.

Not "the budget error survives" — the general form. Both reader.cancel() sites in
inflateBounded are closed by the same helper: the older overflow path, which has carried
this shape since before any budget work, and the budget path added in #6.

Reproduced before anything was touched

The fault is injected at the platform boundary, by substituting DecompressionStream with
one whose cancel() misbehaves. Nothing in src/ is aware of the test.

case	against f057067
overflow path, cancel() rejects	file ACCEPTED instead of refused
budget path, cancel() rejects	file ACCEPTED
the stated reason for refusing	lost
cancel() throws synchronously	file ACCEPTED
cancel() never settles	hangs indefinitely
cancel() works (control)	correctly refused

The mechanism: the rejection replaced the refusal, the outer handler saw something that was
not a MalformedFileError, and returned 'unreadable' — merely undecodable text, which
FilePass reports, removes, and accepts the file for.

The fix

function abandon(reader: { cancel(): Promise<unknown> }): void {
  try {
    void reader.cancel().catch(() => {});
  } catch { /* a source that throws on cancel is still just a source FilePass has finished with */ }
}

The important part is that it does not wait. The first version of this fix did
await reader.cancel() inside a try/catch, which closes the rejection case but not the
one where cancel() never settles. Not waiting closes both, and is less code than awaiting.

No timer or timeout machinery enters product code. The hang is not fixed by bounding the
wait; it is fixed by not having a wait to bound. Cancellation is a courtesy to the stream —
nothing depends on it completing, so nothing looks at how it went.

Regression evidence

Six new cases. Five fail without this change; the sixth is the control, where
cancellation works and the refusal was never in doubt. It stays green either way, which is
the point of having it.

Correction to my own interim finding

While reviewing I reported that a synchronously throwing cancel() was "already covered".
That was measured with the first version of the fix already applied. Against unfixed code it
fails too. The class was wider than I first said, not narrower.

Observed during validation — not attributed with confidence

The first full audit run after the change had one failure in a pre-existing test:
v01-closeout.test.tsx > a reset during processing is not undone when the old run finishes.
That test asserts on 500 ms / 900 ms windows and is already on the P2 list as unit-verified
only, unreachable in the shipped UI.

Counts, so the reader can judge rather than take a claim:

• isolated: 3/3 green
• full suite afterwards: 10/10 green
• baseline without this work: 3/3 green
• so: one failure in eleven full runs with this work, zero in three without

That is not enough to call it unrelated, and it is not claimed to be. The plausible
mechanism is load — the "never settles" case held a 3 s timer while a timing-sensitive UI
test ran. That fallback was shortened to 500 ms, cutting the contention window sixfold, and
the suite has been green since. The underlying test remains structurally fragile; that is
its own P2 item, not part of this change.

Gates

Windows, core.autocrlf=true:

Gate	Result
Product tests	5 files / 43 tests passed
Audit tests	23 files / 316 tests passed (was 22 / 310)
tsc --noEmit	clean
vite build	1.17 s
npm audit --audit-level=high	0 vulnerabilities
git diff --check	clean
git diff audit/	empty — no tracked evidence file changed
git status --porcelain after a full audit run on the committed tree	empty

Scope

src/core/png.ts only, 21 lines added, 2 changed. No PDF, no JPEG, no verification
semantics, no stream abstraction, no dependencies, no product copy changes. No tag, release
or deploy proposed.

🤖 Generated with Claude Code