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

docs/BACKLOG.md

@@ -6025,7 +6025,7 @@ filing.
 
 ## 1114. research an honest pass for ASVS 2.4.1 -- anti-automation on a data plane whose senders are machines and whose intake has no authentication
 
-> 🔢 **Filed 2026-08-08 - not started. RESEARCH item: the goal is an HONEST pass, and "cannot honestly reach pass" is a valid finding.** Value **8/10** · Difficulty **7/10**. ASVS **2.4.1** (L2) currently scores **partial**. The pinned verb asks for anti-automation controls against excessive calls leading to exfiltration, garbage data, quota exhaustion, denial of service, or overuse of costly resources. What holds it short is that no message-rate or volume control exists on the data plane in any configuration -- the product says so in its own documentation at `docs/SECURITY.md:1582`.
+> 🔢 **Filed 2026-08-08 - not started. RESEARCH item: the goal is an HONEST pass, and "cannot honestly reach pass" is a valid finding.** Value **8/10** · Difficulty **7/10**. ASVS **2.4.1** (L2) currently scores **partial**. The pinned verb asks for anti-automation controls against excessive calls leading to exfiltration, garbage data, quota exhaustion, denial of service, or overuse of costly resources. What holds it short is that ~~no message-rate or volume control exists on the data plane in any configuration~~ **[FALSIFIED 2026-08-12 by `e0e979d5`/`b3b278e6` -- struck, not deleted. 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 very cell, so the module knew about this item while this item did not know about the module. THE ITEM STAYS OPEN AND ITS QUESTION HARDENS:** not *does a control exist* (answered, yes) but **can a control that ships OFF be an honest pass.** The `docs/SECURITY.md:1582` citation below 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.]** -- the product says so in its own documentation at `docs/SECURITY.md:1582`.
 
 **Cluster:** Security / ASVS remediation research. **Priority:** P1. **Verdict:** research.
 **Severity:** on a first deployment, any sender able to reach the NIC-bound data plane could submit unbounded messages, each durably persisted before the ACK -- an unbounded store-growth and denial-of-service exposure. MLLP has neither intake authentication nor rate limiting, so there is no actor to charge a budget against.
@@ -7009,7 +7009,7 @@ filing.
 
 **The pinned verb.** "Verify that only approved hash functions are used for general cryptographic use cases, including digital signatures, HMAC, KDF, and random bit generation. Disallowed hash functions, such as MD5, must not be used for any cryptographic purpose."
 
-**What holds it short today.** The TOTP primitive is RFC 6238 HMAC-SHA1 with no SHA-256 or SHA-512 option, and the enrolment URI advertises `algorithm=SHA1` (`totp.py:170`). The de-identification seed is a keyed BLAKE2b with a 128-bit digest, twinned byte-identically at `tee/anon/keying.py` and formally inventoried at `scripts/security/crypto_inventory_check.py:86`; BLAKE2b is not on the NIST approved list. A third SHA-1 use, `auth/policy.py:150`, is marked `usedforsecurity=False` as the HIBP corpus index. No MD5 implementation exists; the token appears once as a rejected value in a test asserting `config/wiring.py:3885` refuses `ws_password_type='md5'`.
+**What holds it short today.** ~~The TOTP primitive is RFC 6238 HMAC-SHA1 with no SHA-256 or SHA-512 option, and the enrolment URI advertises `algorithm=SHA1` (`totp.py:170`).~~ **[FALSIFIED 2026-08-12 by PR #325 (`0ace6bb6`) -- struck, not deleted.** `auth/totp.py:84` is `_TOTP_DIGEST = hashlib.sha256`; `:85` DERIVES `_TOTP_ALGORITHM` from it so the two cannot be edited apart; `:91` reads *"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 and nobody has measured it* -- is **MOOT**: it shipped as a hard cutover with the authenticator cost accepted. **This is a 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.]** The de-identification seed is a keyed BLAKE2b with a 128-bit digest, twinned byte-identically at `tee/anon/keying.py` and formally inventoried at `scripts/security/crypto_inventory_check.py:86`; BLAKE2b is not on the NIST approved list. A third SHA-1 use, `auth/policy.py:150`, is marked `usedforsecurity=False` as the HIBP corpus index. No MD5 implementation exists; the token appears once as a rejected value in a test asserting `config/wiring.py:3885` refuses `ws_password_type='md5'`.
 
 **The research question.** SHA-1 is what makes TOTP universally interoperable, so the unknown is real authenticator-app support for SHA-256 TOTP across the apps a hospital workforce actually uses -- RFC 6238 permits it, app support is the blocker, and nobody has measured it. Separately and independently: is the keyed BLAKE2b doing a cryptographic job this verb reaches, or is it, like the HIBP index, a non-cryptographic use? Settle that before touching it. Third, prior to both: the scorecard records a contested reading -- NIST SP 800-131A Rev 2 still permits SHA-1 for HMAC until 2030 -- so establish which list "approved" binds to, because that answer changes the TOTP verdict and does not rescue BLAKE2b either way.