geolocation: add target_update_count to GeoProbe for lightweight target change detection

[ben-dz]

Closes #3304

Summary of Changes

• Add target_update_count: u32 field to the onchain GeoProbe account, incremented by add_target and remove_target processors. Non-breaking: uses BorshDeserializeIncremental so existing accounts default to 0.
• Extend the Go SDK to deserialize the new field with backward compatibility (EOF → 0).
• Wire up the geoprobe-agent so parent discovery publishes the counter via a shared atomic.Uint32, and target discovery skips the expensive GetGeolocationUsers RPC scan when the counter hasn't changed. A forced full refresh every 5th tick (~5 min at 60s intervals) catches non-counter changes like payment status updates.

Diff Breakdown

Category	Files	Lines (+/-)	Net
Core logic	5	+109 / -53	+56
Scaffolding	8	+11 / -0	+11
Tests	6	+278 / -25	+253

~80% of the diff is tests; core logic is compact.

Key files (click to expand)

• controlplane/telemetry/internal/geoprobe/target_discovery.go — skip-scan logic: check shared target_update_count atomic, force full refresh every 5th tick, nil-return for skipped scans
• smartcontract/programs/doublezero-geolocation/src/state/geo_probe.rs — add target_update_count field with BorshDeserializeIncremental, backward-compat deserialization, updated Display/tests
• controlplane/telemetry/internal/geoprobe/onchain_discovery.go — parent discovery stores probe.TargetUpdateCount into shared atomic after each poll
• controlplane/telemetry/cmd/geoprobe-agent/main.go — create shared atomic.Uint32, pass to both parent and target discovery configs
• sdk/geolocation/go/state.go — add TargetUpdateCount uint32 to Go GeoProbe struct, backward-compat deserialization

Testing Verification

• Rust unit tests pass (39 geolocation lib tests), including new backward-compat test that truncates serialized data to simulate pre-target_update_count accounts
• Integration test assertions added: target_update_count increments after add_target/remove_target, unchanged after update_payment_status
• Go SDK round-trip and backward-compat tests pass
• 4 new geoprobe-agent target discovery tests: counter unchanged → scan skipped, counter changed → full scan, forced full refresh ignores counter, nil counter → always scans
• New parent discovery test verifies target_update_count is stored in the shared atomic
• Full workspace cargo build, cargo clippy, rust-fmt, go test, golangci-lint all pass

[nikw9944]

I think there's a race condition because:

• parent discovery and target discovery run in parallel every 60s
• parent discovery updates probe.TargetUpdateCount (controlplane/telemetry/internal/geoprobe/onchain_discovery.go:161) but target discovery reads from it (controlplane/telemetry/internal/geoprobe/target_discovery.go:155
• whether the read or write happens first is not deterministic
• if the read happens first, the update won't be noticed for another polling cycle

Fix it by running target discovery immediately after parent discovery?

[nikw9944]

We should probably explicitly handle (and log) when the counter wraps.

[ben-dz]

We should probably explicitly handle (and log) when the counter wraps.

I don't think it's relevant. We're only ever looking for change. 0 to 1 is functionally identical to 4,294,967,295 to 0.