fix(coord): unbrick the backlog allocator — the partition guard measured the wrong maximum

[wshallwshall]

alloc.ps1 -Kind backlog refused every allocation, repo-wide, blocking at least two sessions from filing items and blocking PR #105 from renumbering an illegal pre-partition number.

What broke

One number served two incompatible purposes. Get-Floor returns the maximum over every ## N. heading across both backlog files on every ref, and the script used that single value for:

• the emit start — max($observed, floor - 1) + 1. Wants the union max, so a number is never re-issued. Correct as written.
• the residual detector — if ($observed -ge $PublicBacklogFloor) { throw }. Wants the maintainer-internal sequence's high-water, to catch the internal ledger creeping up on the partition. It read the union instead.

Public items are supposed to sit at or above the floor — that is the whole of the #107 partition design — so the detector fired on the system working exactly as intended. BACKLOG #1000 was simply the first legitimate public number to get there, and from that moment 1000 >= 1000 held forever.

Raising PUBLIC_BACKLOG_FLOOR, which the error message itself recommended, would have re-bricked at the new floor the moment a public item reached it. It is a workaround, not a fix.

What changed

Two measurements where there was one: Floor (max over everything swept — what must I not re-issue?, includes public numbers) and SubFloorMax (max below the partition — how much runway does the internal sequence have?).

The refusal is removed rather than made unreachable. Once an internal item is allocated at or above the boundary it is indistinguishable, in the published files, from a legitimate public item at the same number — both are ## N. with N ≥ floor. There is no attribute that separates them, so the arrival case cannot be detected from this data. A refusal branch that cannot fire reads as protection and is worse than none, so the detector now only warns, and the comment states that the limit is the data rather than the implementation.

-ShowFloor was a lying instrument and is fixed in the same commit. It returned before the guard, so it printed a confident next : 1001 while a real allocation threw. Anyone diagnosing this with the inspector concluded the allocator was fine. $residualWarning is now computed above the -ShowFloor block, so the preview and the real run read one shared expression.

Verified by the reviewer, not just reported

• Fail-on-purpose has teeth. Re-planting $observed -ge $PublicBacklogFloor turns test_the_residual_detector_does_not_read_the_whole_set_maximum red; removing it turns it green. Reproduced independently.
• -ShowFloor now reports floor 1001 / sub-floor 353 / next 1002, no refusal, guard quiet (353 is far below the 900 warn tier). ADR allocation unaffected.
• 29 tests pass; ruff clean.

One measurement worth recording, because both the author and the reviewer initially got it backwards

The old comment claimed "Get-Floor already swept every ref, internal ones included." That claim is TRUE — measured: 490 vault-ish remote-tracking refs present, 489 carrying docs/BACKLOG.md, and 67 item numbers living only there, including #240–#247, precisely the numbers the Ledger erratum records as re-issued over cited work. The sweep is why the floor is trustworthy.

What was false was the inference built on top of it: seeing internal numbers is not the same as being able to attribute one. The replacement comment separates the true claim from the false inference instead of deleting both.

BACKLOG #1001 is a permanent hole

A regression probe spent it as a real allocation before the test seam was in view. Precedent is #315/#317, probe allocations made verifying the previous floor fix, so it is left as a documented hole rather than hand-releasing a claim — which would establish a "release the verb by hand" habit the registry design deliberately refuses. The next backlog number is #1002.

Ledger

No BACKLOG number (the allocator was the broken thing) and no ADR: this restores intended behaviour rather than deciding anything, and ADR 0115 is not the partition ADR — 8e6e7fa3 touches three files, none under docs/adr/. Repo precedent for gate fixes of this class is a plain commit carrying the reasoning.