fix(call): handle non-standard mid-call cc messages to prevent T103 timeout

[EdamAme-x]

Summary

Addresses #198 (1:1 audio call drops with T103 ~10s after answer).

After conn_req/conn_rsp, the relay sends a flood of cc messages in a flat protobuf format that bypasses the standard cc_msg oneof wrapper. These messages were invisible to decodePlanetCcMsg (field 1 is a varint, not bytes, so bodyTag was never set), and the relay tore down the call with T103 after ~10s of no response.

What the relay sends (from #198 comment)

Shape A (~100+/s, in cc channel):

{ 1: 16, 2: <monotonic_seq>, 3: 300, 4: <~500B blob> }

Field 1 = 16 matches CC_MSG.UPD_RSP. This uses a flat protobuf, NOT the standard wrapCcMsg oneof format.

Shape B (periodic, in sc channel):

{ 1: 0, 2: 500, 3: 16, 4: 16, 5: [{1:<ts>, 2:<ts>}, ...] }

RTCP-equivalent media statistics — currently stored as scBytes but never processed.

Changes

• decodePlanetCcMsg: fall back to flat-format parsing when standard header+body fields are absent; expose rawFields on DecodedPlanetCcMsg for downstream handling
• packCcUpdRsp: new encoder for flat-format UPD_RSP echo messages
• PlanetTransport.#handleFlatCcUpd: detects flat UPD_RSP (bodyTag=16) cc messages and starts a periodic cc-level echo timer matching the relay's interval (default 300ms)
• Timer is cleaned up on close()

⚠️ Speculative — needs manual testing

This fix is a best-effort hypothesis based on the decoded captures in the issue. The exact response format expected by the relay is not confirmed. The approach:

1. Parse the flat cc messages to identify them (this part is solid)
2. Echo back periodic UPD_RSP at the relay's interval (speculative — could be wrong format/type)

To verify: Run a 1:1 audio call and check if it survives past ~10s without T103. If T103 still fires, the response format or message type needs adjustment.

Test plan

• deno check passes
• All 209 existing tests pass
• Manual: 1:1 audio call must survive past 10s without T103
• Manual: Verify Shape A messages are now logged as cc_flat_16 / upd_rsp instead of cc:"" ccTag:0

🤖 Generated with Claude Code

[EdamAme-x]

Closing this PR — the UPD_RSP keepalive approach was based on speculation and turns out to be wrong. The real T103 cause is the missing DATA channel SRTP keying + MC (BEPI) handshake for 1:1 calls, as diagnosed in detail by @botnick in #198. A new PR with the correct fix is coming.