feat(probeverdict): pure verdict logic for geolocation probe submissions

[Ryanmello07]

New standalone probeverdict package: pure decision logic, no I/O, no DB, no dependencies beyond time. Turns a geolocation probe submission into verified / unverified / suspect, decoupled entirely from the transport that produced the submission.

Entirely new files — this applies to main with zero conflicts. The branch is a clean cherry-pick onto upstream/main (69ae7789); it adds probeverdict/probeverdict.go and probeverdict/probeverdict_test.go and touches no existing file, so nothing else in the repo can regress.

Rules

Only the two corroboration rules that need no external reference point:

1. No country consensus → unverified / no_consensus
2. Country changed from a prior observation less than 24h old → suspect / unstable. Outside that window a changed country is a legitimate correction, not a flip-flop.

Everything else verifies. suspect verdicts are advisory — this package decides nothing about provider selection.

Two omissions from Input that are load-bearing

No mmdb-derived country field. A provider's egress country legitimately differs from where its control connection originates — that divergence is the entire point of egress geolocation, and treating it as suspicious would flag honest providers wholesale. Keeping the field off Input makes the rule structural: a caller cannot get it wrong because there is nothing to pass.

No RTT or coordinate fields, and no great-circle helper. An RTT-distance floor (light-speed minimum RTT for a claimed distance) was designed for this package and deliberately dropped before implementation. It needs a fixed reference point for where the RTT was measured from, and network_client_connection.connection_block exists precisely because more than one such point can exist. A single hardcoded origin is wrong for any provider measured against a different instance, and the error is not one-sided: a misplaced origin can flag an honest, correctly-placed provider as suspect rather than only loosening the check. Weighed against a check already defeatable by a provider willing to add artificial delay to its own latency, it was not worth carrying the reference-point problem. Verdict.Reason never takes the value "rtt_impossible".

The package doc comment records both decisions inline so a future reader does not reintroduce them by accident.

Tests

5 tests, written before the implementation, all passing:

• TestEvaluateNoConsensusIsUnverified
• TestEvaluateCountryFlipFlopIsSuspect
• TestEvaluateCountryChangeOutsideWindowIsVerified
• TestEvaluateMmdbDivergenceAloneIsNotSuspect — a clean first-time probe verifies regardless of what mmdb would have said
• TestInputHasNoMmdbRttOrCoordinateFields — reflection over Input's field set, pinning both omissions above

The last is the guard with teeth: neither omission can be asserted behaviourally, since both are the absence of an input. Confirmed it fails as intended by temporarily adding an ObservedRTT field:

probeverdict_test.go:90: Input has an unexpected field "ObservedRTT": mmdb-country, RTT and coordinate fields are deliberately absent from Input
probeverdict_test.go:95: Input has 6 fields, want exactly 5
--- FAIL: TestInputHasNoMmdbRttOrCoordinateFields

Verification on this branch

• go test ./probeverdict/ -v — 5/5 PASS
• go build ./... — clean
• go vet ./... — clean
• gofmt -l probeverdict/ — clean

The package is pure Go with no DB, so the tests run standalone without a local stack.