Require a valid proof of work for a token, not just a good score

[cport1]

A bare curl was issued a valid token — ten times out of ten, on all three servers:

$ curl -X POST /api/verify -d '{"siteKey":"demo-site-key","signals":{}}'
tokens minted: 10 / 10

No browser, no proof of work, a curl User-Agent, empty signals. Every token passed siteverify. Reproduced against v1.21.0, so it predates the siteverify work.

Why the detectors did not stop it

They fired. A forged solution referencing a challenge that was never issued produced seven detections and still scored 0.4003, under the 0.5 success threshold.

calculateFinalScore is a weighted sum, so a category contributes at most its own weight however conclusive it is. bot is weighted 0.13; every PoW failure firing at once reaches 0.9986 under noisy-OR, which is 0.1298 of the final score — 0.37 short, permanently. dispositiveFloor's own doc comment diagnoses this exact failure, but the mark had only been applied to navigator.webdriver and the ChromeDriver/Puppeteer globals, never to the proof of work — whose own code comment reads "hard fail".

The fix

• A proof of work is a precondition, checked outside the score: success = score < 0.5 && hostnameAllowed && powSatisfied. Gating here means no future reweighting can reopen it, and it holds even if the dispositive floor is lowered.
• The three PoW failures are marked Dispositive (absent, unverifiable, nonce-unbound), so the reported score is honest too — 0.9 rather than 0.4.
• Refusals name the failed precondition (pow_not_satisfied / hostname_not_allowed) via a reason field.

No effect on legitimate traffic

The widget already solves a challenge on every path and aborts rather than submit without one. Measured on the bench harness, which completes the real handshake:

	before	after
human FPR	0.00% (0/126)	0.00% (0/126)
human median score	0.097	0.097
agent TPR	97.33%	97.33%
curl bulk-mint	10/10 tokens	0/10 tokens

Bench gate exits 0.

Tests

E2E suite's eight "gets low score" assertions posted no PoW and so floored at 0.9; they now complete the real handshake via a helper that reuses the bench solver rather than duplicating the scheme. Detection-only assertions still skip it — whether a payload trips a detector does not depend on the handshake. 104 → 107 assertions, all passing on Node.

Go and Python regression tests cover a withheld token, the dispositive floor, a forged solution, the reported reason, and — pinning why the gate must exist — that the bot category alone cannot reach the threshold.

The 5 Go / 13 Python E2E failures are the documented pre-existing divergences, verified identical against the pre-change build.

Breaking

Anyone calling /api/verify directly from a custom client must now complete the handshake. There is no flag to restore the old behaviour — it was a bypass, not a feature. See Upgrading to 1.23.0.