backlog: correct my own #1131 amendment, strike a false limb in #1020, and file #1236

[wshallwshall]

Docs-only, four edits in one commit. #1131, #1020 and #1236 all OPEN.

1. I landed a false claim in fd2d8325, and this retracts it

I wrote that the step-up gate is "a partial answer to exactly that abuse surface, which nothing in the record credits." Both halves are wrong.

• The record is not silent. Cell 6.3.8 already describes "the only reset is administrator-initiated behind a step-up gate." So 6.1.1 omits it rather than the record lacking it -- narrower, and a different defect.
• The sign is inverted. 6.1.1 is about malicious lockout, and a stronger gate on the sole administrative remedy makes recovery harder. It is a constraint on the remedy, not a mitigating control.

How it happened, because that is the reusable part: I verified the step-up exists at auth_routes.py:757 -- real, still true. I never verified its interpretation against the cell's axis; I inherited that from the report. Measuring the fact and adopting the framing are two acts, and I performed one.

This is the shape the playbook already records with me as the corrector: a correction arrives pre-framed as the more-examined claim, so it lands with more weight and less scrutiny than the thing it replaces. The lane caught it by re-deriving the cell rather than accepting a summary.

2. The disclosure gap is not one parenthetical

docs/SECURITY.md:59 reads "never auto-disabled, so a single-admin deployment can't be locked out" -- flatly denying what #1131 is about, 1,485 lines before the known :1544 parenthetical, and the one a reader greps for. Two further collisions at :741 and :782.

A fix that edits only :1544 leaves the contradiction that is read first.

3. #1020's own amendment introduced a false premise

Its rank row offers three limbs refuting "no administrative unlock path". The third -- "the documented break-glass is a sealed file" -- is not an unlock path: _emit_bootstrap_admin writes it only for a newly created account gated on an empty users table, so it cannot recover an existing locked admin.

And for a sole administrator the second limb fails too: an admin reset needs a second admin, and self-reset is refused. Only the 15-minute expiry survives, which is the lock lapsing rather than a recovery path.

An amendment written to correct a premise introduced a false one.

4. #1236 filed -- and deliberately not riding #1131

The sole-administrator dead end is an availability defect in the shipped control, not a documentation gap. Five exits, each individually deliberate, all closing at once for a one-administrator site:

bootstrap account is literally "admin"     service.py:71
created with no email -> notifier returns  security_notify.py:127-131
self-reset refused                         auth_routes.py:762
admin reset needs ANOTHER admin            -- there is not one
re-bootstrap only on an EMPTY users table  service.py:529
no argparse subcommand manages users       -- no offline path either

If it rode #1131, a documentation edit would close the item while the defect went untracked.

Duplicate-checked before allocating: #1020 is adjacent but different -- notifications cannot reach the bootstrap admin; #1236 is that a locked admin cannot recover. Different fixes, same emailless-bootstrap root.