fix: the seven hex.audit advisories, and seven image justifications the scan retired

[HackTuah]

Five things turn main's checks red as of 2026-10-19 without any change to the tree. This puts them right, and nothing else.

gate: seven advisories in mix hex.audit

Package	Was	Now	Advisories
bandit	1.12.5	1.13.1	EEF-CVE-2026-105659 (high), EEF-CVE-2026-105660 (medium); fixed in 1.13.0
decimal	3.1.1	3.2.0	EEF-CVE-2026-97853 (medium); fixed in 3.1.2
protobuf	0.17.0	0.17.1	EEF-CVE-2026-104635 (high); fixed in 0.17.1
hex_core	0.19.0	0.20.1	EEF-CVE-2026-103502, EEF-CVE-2026-105274, EEF-CVE-2026-96596; fixed in 0.20.1
sbom	0.11.0	0.12.0	none; 0.11 pinned hex_core ~> 0.19.0
thousand_island	1.5.0	1.6.0	none; moved with bandit

Fixed versions are from each advisory's OSV record. protobuf and hex_core reach the tree only through sbom, which is dev and test only and ships in no artifact; bandit and decimal ship. mix.exs is unchanged: every new version is inside its existing requirement. THIRD_PARTY_LICENSES.md is regenerated (versions only; no licence changed), and mix versions.gen --check passes unchanged.

headless-image: seven justifications for findings the scan no longer reports

mix trinity.image.findings fails on a justification whose finding the scan no longer reports, which is what it did (run 39257269071, grype database built 2026-10-19T06:39Z). Read from that run's grype.json:

• pcre2 and pcre2-syntax, six rows (CVE-2026-86145, CVE-2026-89161, CVE-2026-103111, each on both packages). The base now carries 10.40-7.el9_8; the rows were for 10.40-6.el9, and the scan reports none of the three against the new build. The file's own rule applies: upgrading the package retires the row.
• openssl-libs, CVE-2026-84782. Same package version, 1:3.5.8-2.el9_8, and the finding is gone from the scan. Red Hat's security data for the CVE names openssl-1:3.5.8-2.el9_8 as the fixed release (RHSA-2026:77396), so the image already carries the fix.

The CVE-2026-75804 row stays; the scan still reports it. The RA-5 row in docs/regulated/control-mapping.md said "the image's scan fails today" for OTP findings that 28.5.0.7 fixed in slice 130; it now states the rule instead of a status.

gate: Hex is pinned to the archive the image pins

The first run of this pull request failed at trinity.third_party_licenses --check with "THIRD_PARTY_LICENSES.md does not match the bill of materials", which a clean local checkout of the same head does not reproduce. The cause is in the runner: setup-beam's mix local.hex --force installed Hex 2.5.3 (released 2026-10-14), and the bill names the running Hex, while the tree records 2.5.1. main's last gate run was 2026-10-08, before Hex 2.5.2 and 2.5.3, so every branch would now fail the same way.

The image already installs Hex 2.5.1 from https://builds.hex.pm/installs/1.20.0/hex-2.5.1-otp-28.ez, checked against the SHA-512 Hex publishes in installs/hex.csv (ci/ironbank/hardening_manifest.yaml). The gate and postgres jobs and the OTP canary's flip job now do the same (install-hex: false, then that archive, sha512sum -c). A Hex move becomes a deliberate pin change instead of a red gate.

postgres: an MCP client test that could not see the state it waited for

Trinity.MCP.ClientTest AC6 kills the stdio server and polls for :down. The client is :down only for its reconnect backoff, 50 ms in the suite, and the poll interval is also 50 ms, so a quick reconnect passed through unseen and every later poll read :ready ("waited for [:down, :connecting], last seen ... status: :ready"). A 1 ms backoff reproduces it three times in three; this test now sets a 1 s backoff, so :down lasts twenty polls. The assertions are unchanged. Passed five times in five locally after the change.

gate (pull_request run): a boot test that read the boot receipt before it was written

Trinity.SecretsBootNodeTest AC4's child script read Trinity.Receipts.boot_receipt() straight after Application.ensure_all_started/1. The receipt is written by Trinity.Effects.Boot, a transient task the application starts, so start can return first; on run 39312232506 it did, and the script raised BadMapError ... nil. The push run of the same head passed. The script now polls for the receipt, as TrinityWeb.Auth.BootRefusalNodeTest's already does for the same reason, and test/test_helper.exs waits on the same task. Not reproduced locally (five isolated boots found the receipt present at once); the mechanism is the task's own start, use Task, restart: :transient.

Evidence

• mix hex.audit: "No retired or security advisory packages found".
• mix gate: every step green; the suite was 1309/1310, the one failure Trinity.SandboxTest "more work reports more reductions" with {:timeout, 1000} on return 1+1 at load average 15.6, the 1 s budget already filed. Run alone: 13 of 13 pass.
• headless-image is read on this PR's own run.