cs2: include channel number and queue depth in pop buffer error

[zealllot]

Problem

When a cs2 data channel's pop buffer overflows, the error doesn't say which channel filled up:

miss: read media: cs2: pop buffer is full

The read media prefix comes from whichever producer noticed the connection had died — it does not mean the media channel is the one that overflowed. worker() tears down the entire connection when any channel's Push fails (pkg/xiaomi/miss/cs2/conn.go:159-162), so a full command queue also surfaces as a "read media" error.

Change

One line, so the source is unambiguous:

miss: read media: cs2: ch0 (queue 10/10): pop buffer is full

Why this matters

There are currently three open PRs targeting this same log line, and they disagree about the root cause:

• fix(xiaomi): drain command channel to prevent cs2 buffer overflow #2280 and Fix Xiaomi CS2 pop buffer full error #2307 attribute it to the command channel (ch0, cap 10) never being drained after login.
• Fix xiaomi/cs2 stream restart on pop buffer overflow #2377 attributes it to the media channel (ch2) filling up behind slow consumers, and adds a buffer= URL param that only resizes ch2.

Both diagnoses are plausible from the current message, and a reporter cannot tell which one applies to their logs. With the channel number present, triage becomes a single grep.

Evidence

On my setup (xiaomi.camera.083ac1, cs2+tcp, one consumer through the rtsp loopback) a binary built from this branch shows it is unambiguously the command channel:

17:48:10 WRN internal/streams/producer.go:170 > error="miss: read media: cs2: ch0 (queue 10/10): pop buffer is full"

It recurs every ~130–170 s, which lines up with ch0's cap of 10 against a camera sending roughly one control message every 13–17 s. Consistent with that, ReadCommand() is called exactly once in the tree — pkg/xiaomi/miss/client.go:113, during login — so nothing consumes ch0 afterwards; everything past login is write-only (StartMedia / StopMedia / StartAudio / StartSpeaker). That matches #2280's analysis for this camera model.

Scope

This PR deliberately does not fix the overflow — it only makes the existing error actionable, so it stays orthogonal to whichever of the three fixes you prefer.