docs(adr): retract the 74 GiB extrapolation in ADR 0087, in place

[wshallwshall]

A ratified ADR on main states an extrapolation as a measurement. This retracts it in place.

The figure was refuted by an adversarial pass run by the seat that produced it. I re-checked each defect against the files before making this change rather than acting on the retraction alone.

The three defects, each sufficient alone

#	Defect	Verified how
1	Wrong multiplier. ADR 0052 AC-2 commits to "1,500 concurrent connections" — "inbound" does not appear. Children exist per traffic-carrying inbound.	Read AC-2 on origin/main
2	Linearity never measured. Every result JSON records worker_tree_uss_mb, worker_tree_rss_mb, worker_tree_processes singular — one tree, five files, no scaling series.	Parsed all five JSONs
3	Resident set is bounded by installed RAM. Tier is 16 GB, bench box 31.7 GiB. 74 GiB resident is not a quantity a host can exhibit; the outcome is paging and spawn failure. A demand figure wants private commit charge.	Definitional, against the recorded host

Retracted in place, not deleted

Per this project's correction rule, the withdrawn sentence is quoted inside the retraction with why it was wrong. Deleting an error invites the next reader to re-derive it — and this one had already been re-derived once, in a backlog row, before anyone checked it.

What stands, unchanged

• The per-child measurement: ~50 MiB unique / ~77 MiB resident. That was measured and it is correct.
• The constraint itself, which is stronger without the extrapolation. ADR 0052 AC-2 requires 1,500 concurrent connections "without per-connection-worker exhaustion (fd/socket/worker-task limits)". At mode=subprocess the engine holds one never-pooled worker tree per traffic-carrying inbound — two processes each, two daemon threads, three pipe fds, a job-object handle. That is precisely the resource class AC-2 names, and ADR 0052 records its 1,500-connection axis as unvalidated with no harness.

No decision, boundary or acceptance criterion of ADR 0087 changes. The Status line records the amendment in the same form as the 2026-08-04 one.

Why this is its own PR

Amending a ratified ADR is a deliberate act and should not ride in a remediation PR — the Manager seat declined to do it from one, and was right to. The owner was asked directly and chose to amend rather than let a backlog row carry the correction while the ADR kept asserting the figure.

Checks

Docs-only, one file. pytest -k relative_link passes (2 passed) — both new relative links resolve. Hosted-only legs unread from here.

Co-Authored-By: Claude Opus 5 noreply@anthropic.com

[github-actions]

@wshallwshall

This pull request is green and nobody has marked it read.

Every check that has reported is passing and the reviewed label is absent, so
a reviewer has read this is the only thing between it and a merge. Nothing else reports that, which is
why this comment exists (BACKLOG #1413).

To clear it, IN THIS ORDER:

1. If the branch is behind main, update it FIRST: gh pr update-branch --repo MEFORORG/MessageFoundry 932.
   That push fires synchronize, and synchronize REMOVES the reviewed label. Labelling
   before updating throws the label away and costs a round trip.
2. Read the diff.
3. gh pr edit 932 --repo MEFORORG/MessageFoundry --add-label reviewed

DO NOT TRIAGE THIS FROM mergeStateStatus. It returns one value with precedence, so BEHIND,
DIRTY and UNSTABLE each mask the missing check -- the requirement is invisible until you act on
something else. This check never reads that field; see scripts/ci/check_unread_prs.py.

A seat can find every pull request in this state in one call: gh pr list --label unread.
The label is withdrawn automatically once this pull request leaves the state.

The reviewed label is a PROCESS gate. It records that a step happened. It does not
establish that an independent party looked, and nothing here should be read as saying it does.