Bind OOB findings to validated matching callback tokens

[tayfuryldz]

Context

HeaderProof promotes blind_header_oob_confirmed to a high-severity, high-confidence, cross_request_confirmed finding when the configured OOB API returns any non-empty events list. The scanner does not independently bind each returned event to the exact probe token before promotion.

This violates the evidence-first invariant: an unrelated callback must never satisfy another probe's technical gate.

Reproduction

I reproduced this on current main in two layers.

Direct detector boundary:

• probe token: expected-token
• returned event: token=wrong-token, protocol=unrelated
• result: blind_header_oob_confirmed
• severity: high
• confidence: high
• technical_gate: passed
• state: cross_request_confirmed

Full OOB query chain:

• wait_for_event() requested /api/events/expected-token from a controlled local API;
• the API returned a syntactically valid events array containing only token=wrong-token;
• query_events()/wait_for_event() accepted it;
• analyze_oob_header_probe() promoted it to the same confirmed finding.

The resulting evidence records oob_token=expected-token and oob_confirmed=true but does not preserve enough of the returned event identity to show that the callback actually belonged to wrong-token.

Required invariant

A blind OOB finding may pass its technical gate only when callback evidence is cryptographically/random-token correlated to the exact probe that generated it. Endpoint path filtering by an OOB service is not sufficient as the scanner-side trust boundary.

Acceptance criteria

• Reject events whose token does not exactly match the requested probe token.
• Reject malformed events that cannot establish token identity.
• Define and validate the accepted protocol/event schema before promotion.
• The detector must derive oob_confirmed from validated matching events, not bool(events).
• Persist bounded callback evidence sufficient to audit the token/protocol correlation without storing unnecessary sensitive data.
• A wrong-token event cannot produce a finding even if returned from /api/events/.
• Mixed responses containing matching and unrelated events use only validated matching events.
• Existing legitimate HTTP and DNS callback tests continue to promote.
• Add regression coverage for wrong token, missing token, malformed event, unsupported protocol, mixed events, and valid matching HTTP/DNS events.
• Ruff, mypy, and the full pytest suite remain green.

Do not weaken this to a warning-only check. OOB confirmation is currently a finding gate, so correlation must be enforced before the gate passes.