docs(backlog): consolidate eight ledger filings into one PR (BACKLOG #1436, #1441, #1444, #1450, #1457, #1458, #1459, #1460, #1461)

[wshallwshall]

Consolidates eight ledger-only pull requests into one, so nine filings cost one merge cycle instead of eight.

Supersedes and closes: #834 (#1436), #838 (#1444), #850 (#1441), #886 (#1450), #903 (#1457), #925 (#1459), #926 (#1458), #936 (#1460, #1461).

Why one PR and not eight

Every merge invalidates every other open pull request, because branch protection is strict. Eight ledger filings that each append to docs/BACKLOG.md are therefore eight serial cycles, and each one re-dirties the other seven. Consolidating removes seven of those cycles. Nothing about the rows themselves changes.

How it was built, and the trap it avoids

Each branch was merged, not cherry-picked, so every number arrives carried by a real merge parent -- which is what the exemption in ledger_check.py grandfathers. Cherry-picking would strip that parentage and the gate would refuse each number as a fresh allocation by a worktree that does not own it.

Each merge re-applies only that branch's own ## N. sections onto the accumulated file. It never takes a branch's whole ledger. That matters: measured before building, all eight branches are stale enough that taking any one wholesale would have silently reverted #1426, #1440, #1454, #1455 and #1456. All five are asserted present below.

This is also the first real exercise of #905. Merge two refused before that landed, with BLOCKED: BACKLOG item #1436 was not allocated to this worktree, because #1436 had arrived from PR 834 onto HEAD and the gate read only MERGE_HEAD. It passes now.

Verification

Run locally before pushing, with all commit hooks active. No --no-verify was used at any point.

Check	Result
Files changed	docs/BACKLOG.md only
Diff	678 additions, 0 deletions
## N. headings removed	0
Final row count	443 = main's 434 + 9, the target computed before building
Duplicate item numbers	none, asserted after every one of the eight merges
#1426, #1440, #1454, #1455, #1456	all present
scripts/docs/backlog_status_check.py	OK, 680 items, each declaring exactly one status
scripts/hooks/ledger_check.py --ci	exit 0

The one advisory warning is pre-existing: #1426 is open and carries no value or difficulty score. That is advisory by owner ruling (BACKLOG #1455) and never fails the gate.

What a reviewer should check

That the nine rows are the ones the eight superseded pull requests each filed, and nothing else moved. git diff origin/main... on this branch shows additions only.

🤖 Generated with Claude Code

[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 940.
   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 940 --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.