build(worker): raise the pypdf floor and pin to 6.18.0

[waterbro-8]

Not a review vote, and not an acceptance

I am the author of this branch, so under this org's require_code_owner +
require_last_push_approval configuration my own ticket cannot be the one that
clears it. Nothing here asks for a merge, a close, a label, or a tag. The
commitment is only: here is a change, here is what I measured.

Supersedes nothing by itself: #156 is a separate, still-valid Dependabot PR.
See Sequencing below.

What changes

Two files, +39/−39:

• worker/pyproject.toml:31 — "pypdf>=4.0" → "pypdf>=6.18.0"
• worker/uv.lock — pypdf 6.15.0 → 6.18.0, nothing else moves

That is the whole diff. No test, no docs, no CI file, no CHANGELOG.md entry:
grep -i 'pypdf\|numpy\|torch\|dependabot' CHANGELOG.md on main returns
zero dependency-bump entries across its 381 lines, and #156 is 2 files too,
so an entry here would be inventing a convention.

Why the floor is written >=6.18.0 and not >=6.16.1

Three open Dependabot alerts name pypdf in this lock — #71
(GHSA-jp53-mhqp-8xcg, < 6.16.0), #72 (GHSA-763m-79hh-57f2, < 6.16.1),
#73 (GHSA-23w6-3w8w-8484, < 6.16.1). This satisfies all three, the same as
#156, once it is on the default branch.

It additionally takes two upstream releases that have no advisory, so no
alert will ever schedule them:

• 6.17.0 (2026-09-04) — Security (SEC): Limit value for Roman numerals (#4047)
• 6.18.0 (2026-09-07) — Security (SEC): Limit allowed length of indirect object tokens (#4055)

Re-measured for this PR: GET /advisories?affects=pypdf → 43 entries, all
type: reviewed, and the newest first_patched_version anywhere in that set is
6.16.1. Both new entries are the same hardening class as the three above
(bound an unbounded parser input), and the surface is the untrusted one:
worker/mem_worker/processors/pdf.py:79 runs PdfReader(BytesIO(file.data)) on
user-uploaded files.

Writing the floor at 6.18.0 rather than letting the lock alone carry it is the
part that survives a from-scratch resolve. Measured: uv resolves to the newest
release satisfying a floor, not to the floor — >=6.16.1 re-resolved today
lands on 6.18.0, and after the next release it would land past it, in a manifest
whose stated requirement was never 6.18.0.

Evidence

All of it executed on a tarball of main @ 2986fe38175f54d99f15dd38a498708c6ecd88cd
whose tree was proved equal to the remote (.commit.tree.sha
f447ca554377e85ba26090d59882b8d4f2b78731 == git init && git add -A && git write-tree), with the tool CI pins — uv 0.9.27 (ci.yml:185-187) — in a
sanitized env (no mirror/proxy variables; uv lock through a mirror-configured
uv rewrites thousands of URL lines and its "lock is stale" verdict is then
worthless).

#	check	result
1	uv lock on the untouched tree	0 diff lines vs committed worker/uv.lock — the pin is reproducible, so everything below is about the resolve, not a stale tool
2	uv lock after only the constraint edit	Updated pypdf v6.15.0 -> v6.18.0, 76 lock lines
3	name/version pairs, both locks	85 packages each, exactly one difference: pypdf 6.15.0 → 6.18.0
4	uv lock --locked	rc=0 — so the Worker leg's uv sync --frozen (ci.yml:193, UV_FROZEN: "1" at :170) accepts it
5	dist hashes vs the registry	sdist ae58b7d93c22c169ffb02c3b06321c45c4f223b4916536568adb57d789d95d01, wheel 05b762b77bcb9dcb4a7c91fcf5dded585b25bee7269ab3d3001d7c55fa1b324b — byte-identical to pypi.org/pypi/pypdf/json
6	the repo's own fixture (test_processor_logic.py:419) extracted at 6.15.0 / 6.16.1 / 6.18.0 on Python 3.11 (ci.yml:182)	identical page_count, identical sha256(extracted_text) (46e7c072b2684841…, 214 chars), "1800 RMB" in text true on all three, malformed input raises the same PdfStreamError on all three
7	6.18.0's only behavioural change (DEP: Rework configuration value handling (#4044))	grep over the whole tree for overwrite_configuration / apply_configuration / disable_legacy_handling / pypdf.constants → 0 hits; pypdf appears in only 3 files (worker/pyproject.toml, worker/mem_worker/processors/pdf.py, scripts/seed_demo_data.sh)

Checks 1–4 and 7 are the ones CI cannot shortcut; 6 is the one that says "the
worker's PDF path behaves the same", and 4 is the one that says "this lock is
self-consistent". The Worker test leg on the exact head remains the real proof
of the full pipeline (test_processor_logic.py:457) — that runs in CI, I did
not run it here; the local venv has none of the Worker's own dependencies
installed.

About the diff size: of the 76 changed lock lines, 8 are pypdf (specifier,
version, sdist, wheel — each on both sides). The other 68 are uv's marker
renormalisation: the python_full_version >= '3.15' and sys_platform == 'darwin' fork marker hopping between torch 2.13.0 and 2.13.0+cpu (likewise
torchvision 0.28.0 / +cpu), python_full_version narrowing dropping off
numpy / scipy / tifffile, and the resolution-markers list reordering.
That is not avoidable churn I chose: a plain uv lock on either side of a pin
costs 0 lines, but any resolve that moves pypdf pays them — #156's own
+53/−53 is the same shape. No other package's version changes.

Process: this PR is ahead of its issue's readiness gate

AGENTS.md rule 2 says not to implement a material change until its issue has
acceptance criteria and status:ready. Refs #187, which I filed with the AC
list and reproduction steps for exactly this; it is status:needs-triage, and
status:ready is a maintainer's label, not mine to set. So this is a draft,
and undrafting it is the step that should follow that label rather than precede
it. If triage would rather the change go in behind #156, #187 can simply wait.

Sequencing with #156

Both branches touch the same two files, so they will conflict with each other,
not with main.

• If build(deps): bump pypdf from 6.15.0 to 6.16.1 in /worker #156 merges first: rebase this onto the new main — the manifest line
  is a one-token edit and the lock is one uv lock with the pinned tool. I
  offered to do that; it is not something to do unasked.
• If this merges first: build(deps): bump pypdf from 6.15.0 to 6.16.1 in /worker #156's diff is a strict subset of this one and its
  three alerts are dismissed by this branch instead. I am not asking for build(deps): bump pypdf from 6.15.0 to 6.16.1 in /worker #156
  to be closed — it has an in-force APPROVED from PeterGuy326 on its
  current head and I am not in a position to spend someone else's ticket. That
  call, and the release-cadence call about whether 6.17.0/6.18.0 belong in this
  repo's Worker at all, is the owner's.

What I did not do

No review submitted, no vote, no merge, no close, no label change on anything
except the new issue's own labels, no ref moved on #156, no Update branch
clicked anywhere, no CHANGELOG.md edit, no tag, no publish.

[waterbro-8]

Head unchanged; the body needed a tracking-record keyword

The first PR Policy run on this head (34192719765) failed at 05:58:55Z
with Link a tracking record in the PR body. That was my mistake, and the
mechanism is worth writing down for the next person: the gate
(.github/workflows/pr-policy.yml) reads only pullRequest.body — my
commit message says Refs #187, and that does not count. The body referred to
the issue as bold text with no keyword, so the regex had nothing to match.

Fixed by one clause in the Process section: Refs #187, which I filed with the AC list…. No commit was added or rewritten — the head is still
6e7536fe975a, and the only thing that changed is this PR's body.

Re-run 34193405908 → success at 06:08:47Z. Conventional title and linked issue is now green, and so are the other 19 check names on this head, each read
at its own highest check_suite.id. The older failed PR Policy record stays
in the history of this commit, which is expected: commits/<sha>/check-runs
returns every round, not just the current one.

The CI result the body said it had not run

The Evidence table had one honest gap — I wrote that the Worker test leg runs in
CI and that I had not run it here. It has now run here, so here is the readback
from Worker (job 101953897734, success, attempt 1):

uv sync --frozen --extra test --extra dev
 + pypdf==6.18.0
266 passed, 1 skipped in 5.19s

--frozen with UV_FROZEN=1 is the part that matters for this change: CI
resolved nothing, it installed exactly the lock in this diff and the suite
passed on it.

Everything else in this comment is a status record, not new evidence for the
acceptance criteria in #187. Still a draft, still not a review vote, still not
asking for a merge — and #156 is untouched.

[PeterGuy326]

Review result

APPROVE for the current head 6e7536fe975ac60d38f47f25441e1e2f1dd0bfa7.

The diff is limited to the pypdf floor and the locked dependency resolution; git diff --check is clean. The latest head-matched policy run, Go, Worker, Web, PostgreSQL integration, recall, wrapper-compatibility, CodeQL, and dependency-review checks are green. The earlier linked-issue check failure is superseded by the later successful run. This is an approval of the current draft only; it does not mark the draft ready or authorize a release.