serviceability: test atomic user delete+create for the user-PDA migration

[nikw9944]

Reproduces the V1 → V2 user-PDA migration as a program test: close one User account and create another inside a single transaction. get_user_pda derives the User account from (client_ip, user_type), so a reconnect lands on the same address, and Migrate moves a legacy index-derived account onto its V2 address — both are close-then-create within one transaction.

Summary

• Adds tests/user_delete_create_same_tx.rs covering DeleteUser + CreateUser packed into one transaction, at the same V2 PDA (reconnect) and across the V1 → V2 addresses (migration), plus a separate-transaction control.
• Both atomic sequences succeed. The re-created account is rent exempt, byte-identical to the pre-delete state, reuses the tunnel id / tunnel net / dz ip the delete released, and leaves access-pass and device counters at exactly one connection. Closing and re-creating a User PDA in one transaction is not the failure mode.
• Found a migration failure that does reproduce: Migrate onto a V2 address already occupied by a live user fails with system AccountAlreadyInUse (Custom(0)). Nothing prevents the duplicate — a Prepaid access pass does not enforce the per-category user cap, so a reconnect that provisions a V2 user while the legacy V1 account is still around leaves two live User accounts for the same (client_ip, user_type). Those users cannot be migrated until the duplicate is deleted. process_migrate has no check for an occupied target and surfaces only the raw system error.

Tests only — no production code changed.

Testing Verification

• cargo test -p doublezero-serviceability --test user_delete_create_same_tx — 4 tests pass.
• Re-ran the neighbouring user suites (user_migration, user_tests, user_old_test, user_onchain_allocation_test, delete_user_dynamic_accesspass) — all green.
• Verified state after the atomic delete+create, not just the transaction result: account owner and rent exemption, full User struct equality against the pre-delete snapshot, access-pass connection_count/status, and device users_count / unicast_users_count / reference_count.
• Run locally against the native processor only; no SBF toolchain in this environment. cargo test-sbf in CI exercises the same tests under BPF, which is the remaining place a runtime-level difference could show up.

[nikw9944]

WT% is this???