fix(signal): add call_id to Hangup — prevents stale hangup killing new calls

Root cause: Hangup had no call_id field. The relay forwarded hangups to
ALL active calls for a user. When user A hung up call 1 and user B
immediately placed call 2, the relay's processing of A's hangup would
also kill call 2 (race window ~1-2s).

Fix: add optional call_id to Hangup (backwards-compatible via serde
skip_serializing_if). When present, the relay only ends the named call.
Old clients send call_id=None and get the legacy broadcast behavior.

Also: clear pending_path_report in Hangup recv handler and
internal_deregister to prevent stale oneshot channels from blocking
subsequent call setups.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

crates/wzp-crypto/tests/featherchat_compat.rs

@@ -199,6 +199,7 @@ fn wzp_answer_round_trips_through_fc_callsignal() {
 fn wzp_hangup_round_trips_through_fc_callsignal() {
     let hangup = wzp_proto::SignalMessage::Hangup {
         reason: wzp_proto::HangupReason::Normal,
+        call_id: None,
     };
 
     let payload = wzp_client::featherchat::encode_call_payload(&hangup, None, None);
@@ -302,6 +303,7 @@ fn all_signal_types_map_correctly() {
         (
             wzp_proto::SignalMessage::Hangup {
                 reason: wzp_proto::HangupReason::Normal,
+                call_id: None,
             },
             "Hangup",
         ),