geolocation: add target_update_count to GeoProbe for lightweight change detection

[ben-dz]

The geoprobe-agent polls all GeolocationUser accounts every 60s to discover targets assigned to it. Each account can be up to ~284 KB, making this the most expensive RPC call in the agent's loop. To avoid unnecessary scans, add a target_update_count field to the onchain GeoProbe account. The add_target and remove_target instructions already touch the probe for reference_count, so incrementing a second counter is trivial. Since the agent already fetches its own GeoProbe account every 60s for parent discovery, it can check whether the counter has changed before deciding to do the full user scan. The field should use BorshDeserializeIncremental and be appended at the end of the struct, so existing accounts deserialize with a default of 0 — no migration or breaking change required.

Changes that don't go through add_target/remove_target (e.g., payment status updates, user suspension) don't need to increment the counter. A forced full refresh every ~5 minutes catches those cases, which is acceptable given the lower urgency of payment enforcement convergence compared to target routing changes.

[ben-dz]

This is best taken care of after 3012 and 3257 merge in one fell swoop. The issue needs to be updated to reflect that once those have merged, since that work will come in Scope.