backlog: close #1106 (already shipped) and file #1223 -- http_auth_user leaks verbatim

[wshallwshall]

Closes BACKLOG #1106 (already shipped -- see below) and files BACKLOG #1223.

#1223 -- http_auth_user leaks verbatim, and the guard's vocabulary cannot see it

Confirmed by running the shipped redactor on main, not by reading it:

basic_user           redacted=True      http_auth_user       redacted=False   <-- leaks
proxy_user           redacted=True      http_auth_password   redacted=True
username             redacted=True      sign_private_key     redacted=True
ws_username          redacted=True
credential_username  redacted=True

config/wiring.py:847 carries {username, basic_user, proxy_user, ws_username, credential_username} --
masked defence-in-depth, on the stated ground that a username names a principal and can leak
directory structure. http_auth_user is written at transports/http_auth.py:477, across the same
parameter-to-setting boundary #1106 was entirely about: with_signing renames private_key to
sign_private_key; with_http_digest renames user to http_auth_user. Same seam, same omission,
different key. It is the sixth member of a five-member class.

Stated in the conditional (this is a beta with zero deployments): on a first deployment this would
emit an HTTP auth username verbatim from both serializers. It is a defence-in-depth leak of a principal
name, not of a password -- http_auth_password is correctly masked.

The structural half: why two independent-looking guards were both green

The tuple deciding where a sentinel gets injected was:

CREDENTIAL_ISH = ("password", "secret", "token", "key", "credential", "passphrase")

So _is_credential_param("user") is False, _is_credential_param("username") is False, and no guard
had ever injected into a username parameter at all. credential_username matched only by accident,
through credential.

And test_credential_parameter_mapping.py inherits the same blindness by importing the same predicate
-- two independent-looking checks that are blind in exactly the same place by construction, because
they share the real predicate rather than a copy.

Proved by mutation, not by reading: widening the tuple by the single word user reds exactly
with_http_digest -> http_auth_user and nothing else.

The inversion was examined and rejected on evidence

The lane was dispatched believing deny-by-default was probably the structural answer. Measured over the
real 189-key set it is worse in both directions: it over-redacts 14 (four file paths, two URLs, a DB
column name, the odbc_*_key keyword indirections) and under-redacts 4 that are currently masked. And
decisively -- it would not have caught this defect: http_auth_user contains none of its six
substrings.

So the allowlist and the shape rule fail on the same key. The defect was never "the list is a list";
it is that nobody derived the domain. The fix that actually stops the next omission is a test deriving
the injection vocabulary from _SECRET_SETTING_KEYS itself -- red today without the widening, naming
all six usernames, and unable to narrow silently the way a hand-maintained tuple can.

#1106 was already fixed, and the banner says so in those words

e7566082 (PR #300) landed 2026-08-09; _is_secret_setting names sign_private_key and
sign_private_key_password explicitly at config/wiring.py:830. Verified on main: both redact from
both serializers, and it is pinned rather than incidentally green -- reverting that arm turns four
tests red.

The banner read "not started" and a lane was dispatched to build it. A machine-written status field
tracks status, not whether the work exists. The corrected banner records that plainly, and records that
the lane recovering the cost by finding #1223 was luck, not design.

Ledger-only. Verified: #1223 free in the live ledger and the archive; #1106 flips to a single closed
banner; parse_items reads 252 items, 184 open; merges clean onto current main.