Qobuz Connect: two cases where the renderer screen stays empty

[Gjuju]

The renderer screen can come up with nothing on it, for two unrelated reasons.
Both leave qbzactive=1, so the overlay is there, showing nothing.

1. The session is handed over paused

TrackStarted is the only writer of qbzmeta.json, and the file is truncated
when a session ends. The Qobuz app hands a session over paused, though: the
daemon loads the track and waits for a play command, so no TrackStarted is
emitted and the event log just repeats:

- Cover URL: empty
- Update cache: skipped

Measured: qbzactive=1, qbzmeta.json 0 bytes, while the daemon knew the
track, the artist and a position all along.

When the cache is empty, read .current_track from /api/queue (title,
artist, album, duration, artwork, bit depth and sample rate, which rebuild the
same SFORMAT string TrackStarted produces) instead of giving up.

2. A session reconnects mid-track

The Connect branch raises the overlay and tells the front end qbzactive1, but
never says what is on it -- the cache is pushed by TrackStarted and by a
play/pause change only. Reconnecting during a track therefore shows an empty
screen until the next track starts.

Observed: reconnect at 16:25:13 with the cache holding the track that was
playing; the screen stayed blank for two minutes, and filled in only when the
next TrackStarted fired.

Re-send the cache on connect.

Validation

Both on x86_64 and on a Raspberry Pi running stock 10.3.4:

• taking a session without pressing play now shows the track instead of nothing
  (- Daemon metadata: <title> / <artist> in the event log);
• reconnecting mid-track fills the screen immediately.

Four degenerate answers from the daemon were checked for the first case -- empty
queue, unreachable, malformed reply, no artwork -- and each leaves the variables
untouched, so the skip happens exactly as before. The second is guarded on the
cache being non-empty.

Reversibility

40 lines, no deletions. Reverting restores both previous behaviours.