backlog: strike two premises in #1171 and #1114 that merged code has falsified

[wshallwshall]

Docs-only, two lines. Both items stay OPEN -- these are corrections, not closures.

Found by the ASVS tracking lane while reconciling PR #310 and PR #325, routed here because docs/BACKLOG.md is a serialization point and a second writer manufactures conflicts for every open ledger PR. Verified against origin/main before writing, not taken on report.

#1171 -- the SHA-1 clause is dead

the item claims	shipped code
"RFC 6238 HMAC-SHA1 with no SHA-256 or SHA-512 option"	totp.py:84 -- _TOTP_DIGEST = hashlib.sha256
"the enrolment URI advertises algorithm=SHA1 (totp.py:170)"	:85 -- _TOTP_ALGORITHM is derived from the digest so the two cannot be edited apart
	:91 -- "SHA-256 since 2026-08-11, not RFC 4226's SHA-1"

Neither cited token exists. The research question it framed -- app support is the blocker, nobody has measured it -- is moot: it shipped as a hard cutover with the authenticator cost accepted.

Re-scope, not a close. The BLAKE2b limb is untouched and remains the live question, so the SP 800-131A contested-reading paragraph now bears only on BLAKE2b.

#1114 -- the control exists, and the question gets harder

The item claims "no message-rate or volume control exists on the data plane in any configuration." A pacer exists and ships OFF by default. transports/mllp.py:109 calls that "a DELIBERATE DEVIATION from this module's key-absent-means-secure-default convention, ruled 2026-08-11 (ASVS 2.4.1 / 15.2.2)" -- naming this item's own cell.

So the module knew about this item while the item did not know about the module.

It stays open and its question hardens: not does a control exist (answered, yes) but can a control that ships OFF be an honest pass. Closing it on the pacer's existence would answer the easy question and drop the one worth researching. The docs/SECURITY.md:1582 citation also needs re-pointing -- the sentence it quotes was rewritten when the pacer landed, in the same edit that broke ASVS cell 2.1.3's anchor.

Both originals are struck, not deleted

A record of the wrong version is worth more than a clean right answer -- the next reader needs to know the claim was made and why it failed, not just what replaced it.

Two things I got wrong producing this

The first attempt replaced the whole line carrying #1114's false sentence -- and that line also carried the item's status glyph, so the item silently declared no status at all. The canonical parser caught it; reading by eye would not have. The lane's message had said the sentence was inside the banner, which is exactly where a line-level edit is unsafe. Fixed by replacing the clause and leaving the banner untouched.

And I was editing on a branch that merged mid-edit. Re-cut from origin/main and re-applied by content anchor rather than by patch, so nothing was carried across from a stale base.

Not in scope here

The same lane flagged #1111 and #1112 as resting on premises that merged code also killed -- four items, all from reconciling two merges. Those are content questions for their owners, not mechanical strikes, and are deliberately left out of this PR.