[lars-1987]

Summary

An Info value pdf-lib can't type no longer fails the file. It falls back to the value the file holds.

 for each Info field
-  value = pdf-lib getter            # throws, and the whole file fails
+  value = pdf-lib getter
+  if it threw, or gave an Invalid Date
+    value = what the file actually holds
   report it, and remove it if its category is on

Info value	Before	After
Date in words: Monday, 5 January	crash: Error	Reported and removed
Impossible date: D:20261399120000Z	crash: RangeError	Reported and removed
Date, title or keywords that aren't strings	crash: Error	Reported and removed
Empty date	crash: Error	Nothing to report

This also mattered for privacy: a crashed file kept all its metadata, and the person was told it may be damaged.

Evidence

• Before: 7 new tests fail with It may be damaged....
  After: 326 tests pass, typecheck and lint clean.

each bad value  -> found, removed, and a re-read finds nothing
category off    -> reported kept, and still there on a re-read
empty date      -> no error, nothing found

Built site in headless Chrome with the PDF that crashed: Monday, 5 January shown, no failed card or email link, -1 removed, "Re-checked the cleaned file: no metadata left."

The a crash tests used a bad date as their trigger, so they now mock setTitle and save. info: and save steps stay covered.

Merge Danger

Door: two-way

Blast Radius: PDFs

Only changes what happens when pdf-lib can't read an Info value, which used to always fail. Fields it reads normally are unchanged. A non-date raw value now appears in the report as the file wrote it, in the person's own browser only; it doesn't go to telemetry.

The two production crashes aren't proven to be this bug, as neither file can be inspected. A new crash: Error at xmp, custom or save would mean there's a second cause.

[lars-1987]

Looks good.