serviceability: add ReclaimUser to release a user account whose client IP has changed hands

[elitegreg]

Parent: #4193

Problem

A user account is a permanent lease on (client_ip, user_type). Only the owner or a USER_ADMIN holder can release it (.../processors/user/delete.rs:131-139). When the machine behind an IP changes hands, the new operator has no self-service path: create_user_core sees the occupied PDA, finds an owner mismatch, and errors before anything else is evaluated (create_core.rs:205-227). Every one of these turns into a support request.

Proposed change

A ReclaimUser instruction that tears down an existing user account for a caller who can demonstrate present control of its client_ip, and only when the incumbent is not passing traffic.

Guards

1. Proof of present IP control. An IpOwnershipProof for target.client_ip, validated through the same onchain path used for user creation. Depends on RFC-27, "IP Ownership Verification Service for user connection" (RFC-27: IP Ownership Verification Service for user connection #2304), being implemented.
2. Incumbent is not live. bgp_status != Up, read from the state the device's metrics_publisher writes onchain. A session that is up should never be clobbered.
3. Full teardown. Identical to DeleteUser: deallocate resources, decrement device counters, decrement the incumbent's access-pass connection_count, release feed seats.
4. Rent refunds to the original owner, not the caller, so there is no incentive to hunt for reclaimable accounts.
5. Tolerate a missing incumbent access pass (see serviceability: closed access passes and bans leave accounts that can never be cleaned up #4191).

Abuse analysis

Evicting a user requires both a valid proof for its IP and a session that is not up. Those are independent, and neither is available to a remote attacker: a proof for an address you cannot originate from is unobtainable, and an operator actually using the tunnel keeps BGP up. The reclaimer inherits nothing from the incumbent's access pass, and creates a fresh user under their own. Rent goes to the incumbent.

Relationship to the wildcard access-pass question

The original hypothesis was that a 0.0.0.0 access pass makes IP handoff work. It fixes half: the pass stops being IP-bound, and both processors already accept either PDA. The user account stays keyed on the address, so the collision is untouched. Releasing the account needs this instruction.

Dependencies

• RFC-27 (RFC-27: IP Ownership Verification Service for user connection #2304) implemented, for the proof this instruction validates.
• client: refuse to adopt a user account owned by a different keypair #4188, so a stale account is not reporting BGP Up because the new tenant adopted it.

Testing verification

• Reclaim succeeds with a valid proof and an incumbent whose BGP is down; device counters, pass connection_count, and feed seats all settle correctly, and rent lands with the original owner.
• Reclaim is rejected against an incumbent with BGP up.
• Reclaim is rejected with a proof for a different IP, a stale proof, or no proof.
• The reclaimed PDA is immediately usable by a fresh CreateUser from the caller.