test(sip): M6 CP5 (B4) — dynamic authenticated REGISTER + IP-change routing (receiver-side, in-process)

[ryanmurf]

M6 CP5 (B4) — dynamic authenticated REGISTER + IP-change routing: rustisk-side receiver-side proof

Context. The sip-bridge advertises an EPHEMERAL pod IP and REGISTERs; a static contact is wrong
because a pod restart gives it a NEW IP (B4). The rustisk registrar-side mechanism for this ALREADY
EXISTS:

• SipChannelDriver::resolve_endpoint_contact prefers the live registrar binding over the static
  configured contact (issue REGISTER: any configured user's credentials can bind any AoR; registrar bindings are never used for routing #33);
• Registrar::best_contact returns the most-recently-registered non-expired contact.

So a re-REGISTER from a new address updates the routing. What was missing is a committed
receiver-side regression test of the pod-restart-new-IP property. This PR adds it.

RECEIVER-SIDE PROOF (e2e_dynamic_register.rs, real UDP sockets).

1. the bridge digest-REGISTERs from address A (401 → digest → 200 bound);
2. an outbound Dial to the bridge endpoint routes to A — the INVITE datagram lands on A's socket;
3. the bridge "restarts": a NEW socket B re-REGISTERs (digest) from a new address;
4. a subsequent Dial FOLLOWS to B — the INVITE datagram lands on B and NOT on the stale A.

The REGISTER is a genuine digest round-trip (401 challenge → create_digest_response → 200), so it
proves authenticated dynamic registration; the outbound routing is exercised through the real
ChannelDriver::request/call path (direct transport send).

CAPTURED RED. Make Registrar::best_contact oldest-wins instead of newest-wins:

thread 're_register_from_new_ip_reroutes_the_call' panicked:
after restart: the outbound INVITE must FOLLOW to the re-REGISTERed address B

(the INVITE datagram fails to reach B — receiver-side RED).

SCOPE / what remains. This is the in-process rustisk-side mechanism proof. CP5's stated
acceptance also calls for an isolated-Docker container-restart harness (a bridge container
restarted so it comes back with a NEW pod IP on an --internal Docker network, then a call that
routes to the new IP). That containerized harness is a separate proof, run out-of-band, and is NOT
included in this PR — it is flagged for continuation. The rustisk code proven correct here is
exactly what that harness exercises.

GATES. cargo test --workspace --exclude pjsip-shim green; cargo clippy --workspace --exclude pjsip-shim -- -D warnings clean. Rust 1.97.0. No rustisk source change (test-only;
mechanism pre-exists via issue #33).

[ryanmurf]

Review note

This is a test-only PR — it adds e2e_dynamic_register.rs and changes NO rustisk source. The B4 mechanism it proves (resolve_endpoint_contact preferring the live registration, issue #33; Registrar::best_contact newest-wins) already exists on master. Self-review per pr-workflow: no production code changed, no auth/RLS weakening, no assertions removed or loosened, purely additive receiver-side regression coverage. External review not required for this trivial (test-only) diff; the captured RED (oldest-wins best_contact → INVITE fails to follow to B) is in the PR body.

Not included: CP5's isolated-Docker container-restart harness (bridge container restarted with a new pod IP) — flagged as the remaining CP5 acceptance step for continuation.