fix(ci): restore green CI -- bump Go to 1.26.6 and fix the stale e2e expectations

[jbrahy]

Two commits, both required to get main green. Neither is sufficient alone.

What was actually failing, and a correction

I initially attributed main's red CI to the stale e2e test. That was wrong, and the real cause matters more.

CI fails at govulncheck, on five Go standard library vulnerabilities in 1.26.5 (fixed in 1.26.6), reached through net/http, encoding/asn1 and crypto/tls.

The consequence is the important part. Step order in the workflow is:

success  go build
failure  govulncheck
skipped  go test (race + cover)   <- never runs

govulncheck runs before the tests, and its failure skips them entirely. Every CI run since those advisories landed has reported a failure without executing a single Go test.

That is how the stale expectation in 52184d5 (#23) reached main. Its description says "The DB-backed tests were not run locally (no MySQL); CI covers those." CI had already stopped running the tests it was said to cover. The test breakage was real and is reproducible locally -- it just was never what CI was reporting.

1. build: bump the Go toolchain to 1.26.6

go.mod pins the version and CI reads it via go-version-file, so one line moves both. Verified locally under 1.26.6: govulncheck reports no vulnerabilities.

Worth fixing separately: a security scanner that silently disables the test suite when it trips is the wrong ordering. Running go test before govulncheck, or continue-on-error on the scan, keeps test results visible while a stdlib advisory is outstanding. I have not changed the workflow here.

2. fix(api): restore the e2e block path

#23 changed new-device trust_weight from 1.00 to trust.TrustBase (0.50) but left TestEndToEnd_FullLifecycle asserting the old arithmetic:

3 x (BaseWeight 1.0 x trust 0.5 x scam 2.0) = 3.0  ->  "label", not "block"

The assertion message even said 3 fresh scam x trust 1.0 = 6.0, naming a constant that no longer existed.

Why not simply expect "label"

That would go green and delete the coverage. numberA reaching blocked is the only end-to-end exercise of the scoring block path -- numberC reaches block through an admin override, which bypasses scoring entirely. So this gives numberA enough reporters to block for real.

• Six devices, not three. At TrustBase one scam report contributes 1.0 x 0.5 x 2.0 = 1.0, so six score 6.0 against a threshold of 5.0.
• Not five. Five hits the threshold exactly, which is unsafe: reports age a fraction of a second before recompute reads them, so decay is a hair under 1.0 and 5.0 lands just below the >= test.
• numberB goes from two reporters to three for the same reason. Two scored exactly SuspectThreshold -- a latent flake sitting on main today, one second of timing from failing.
• Token distinctness becomes a set membership test rather than hand-enumerated pairs, which does not scale past three.
• A guard up front fails loudly naming the constant that moved, if TrustBase, BaseWeight, BlockThreshold or SuspectThreshold change again.

The behaviour change #23 was hiding

A number now needs five fresh-device scam reports to auto-block, up from three. That is a consequence of #23, not of this PR, but it was invisible while both the assertion was stale and CI was skipping tests. If five is not the intended product behaviour, the fix belongs in the scoring constants rather than in this test.

Verification

Under Go 1.26.6, the full CI gate locally: govulncheck clean, gofmt clean, go vet clean, go test ./... -race -cover green.

Unrelated and untouched: SpamFilterUITests.testLookupFlow also fails on a pristine main.