fix(signalr): don't panic on non-feed SignalR Core frames

[lucvan]

Problem

After F1's live timing moved to the SignalR Core endpoint (livetiming.formula1.com/signalrcore), the realtime service crashes its ingest task within ~15s of connecting, on every published image I tested (4.0.4, 4.0.5, develop, and latest rebuilt after the recent fix: invocation_id missing commit). The HTTP/SSE server keeps running, so the dashboard loads but shows no live data — the failure is silent.

thread 'tokio-rt-worker' panicked at signalr/src/lib.rs:282:
called `Result::unwrap()` on an `Err` value:
Error("missing field `target`", line: 1, column: 10)

Root cause

SignalR Core interleaves protocol frames among the feed invocations — most commonly ping frames {"type":6} (exactly the 10-char message in the panic above), plus completion/close frames. Two places assume a stricter frame shape:

1. listen() .unwrap()s every frame into FeedMessage, which requires a target field. The first ping panics the worker and kills all live data.
2. subscribe() assumes the immediate next frame after the Subscribe invocation is the Completion, so a ping arriving first breaks subscription.

Fix

• listen(): skip frames that don't deserialize as a feed invocation instead of unwrapping (logged at debug).
• subscribe(): read until the Completion whose invocationId matches ours, skipping ping/other frames that may arrive first.

No protocol or struct changes — purely defensive parsing.

Validation

Built from this branch and run against the live endpoint during an active session:

• Connects to wss://livetiming.formula1.com/signalrcore, handshake + subscribe succeed.
• 0 panics / 0 restarts over a full session (vs. crash within ~15s before).
• /api/current serves real session state (full 44-driver list, weather, timing, ExtrapolatedClock/Heartbeat).
• Ping frames now logged as skipping non-feed signalr frame at debug and ignored.

🤖 Generated with Claude Code

[slowlydev]

thanks