backlog: amend #1131 -- an administrative unlock DOES ship, and the regex that missed it could never have found it

[wshallwshall]

Docs-only, one file. #1131 stays OPEN and its question hardens. No new number.

Reported by the ASVS tracking lane after a builder found three things they had not. All four load-bearing claims verified here against origin/main, not relayed.

1. The remedy is stronger than the item credits

api/auth_routes.py:753 routes POST /users/{user_id}/reset-password, and :757 takes Depends(require_step_up(Permission.USERS_MANAGE)) -- the admin re-authenticates; it is not a plain permission check.

That is load-bearing because #1131's own research question says "anything that clears a lock is itself a control an attacker wants, so an unlock route is a candidate with its own abuse surface, not an answer." A step-up is a partial answer to exactly that abuse surface, and nothing in the record credited it.

Coverage is uniform -- failed_attempts=0, locked_until=NULL in store.py, postgres.py and sqlserver.py, two sites each -- so this is not a partial-surface finding.

2. The docs/SECURITY.md:1474 citation is stale

At engine 9d98f339 that line is an unrelated AD row in the comparative-properties table. The disputed parenthetical is at :1544, in the three-limiter anti-automation table. Cite the greppable phrase, not the line number.

3. The method defect, which is the part worth keeping

The filed absence claim searched def admin_unlock|unlock_account|clear_lockout. Measured on main:

def admin_unlock|unlock_account|clear_lockout   ->  0 hits in auth/service.py
def admin_reset_password                        ->  1 hit  in the same file

The regex cannot structurally match the thing that ships. So the zero was a true answer to a question nobody asked, and the item's conclusion -- "no dedicated administrative unlock exists" -- is literally true and materially misleading: an unlock ships, as a side effect of a forced password rotation.

Prescription, now recorded in the item: an absence claim over a CAPABILITY must be written from the STATE, not from plausible function names. "Find every write to locked_until" would have found it; "find every function called something-unlock" never could.

The re-scope

The live question is the adequacy and disclosure of a step-up-gated forced-rotation reset as a remedy for a malicious lockout -- not whether an unlock affordance exists. That is harder than the question filed, which is why this stays open rather than closing on the route's existence.

Why it is worth a commit rather than a correction in passing

This is the same defect family as the day's other measurement errors -- an instrument that cannot see the class it certifies -- but it is the first instance found inside a backlog item's own evidence rather than in tooling. A false conclusion, from a true measurement, by a regex that was never able to answer the question it was written for.