fix: [overlay] suppress dead-signal detection during auto-pause to avoid

[b0g]

When auto-pause is active (auto_paused == true), the recording pipeline is paused and the ring buffer is not fed fresh audio data. This produces stale samples with variance ≈ 0, which falsely triggers the dead-signal detector after 30 frames (0.5s), creating an oscillation cycle:

auto-pause -> dead-signal -> resume -> auto-pause -> ...

The dead-signal alert plays a repeated tone and shows a full-screen "NO SOUND" overlay every ~0.8s, which is disruptive during normal silent periods.

Fix: skip the variance check in the dead-signal detector while auto-pause is active. Also reset silence_notified so that when auto-pause clears (user speaks), the notification flag is fresh.

TDD: 3 unit tests in x11::overlay::tests:

• auto_pause_oscillates_with_dead_signal — proves the oscillation is eliminated
• dead_signal_still_works_without_auto_pause — regression guard: dead-signal works normally when auto-pause is off
• dead_signal_recovers_when_audio_returns — regression guard: dead-signal clears when real audio resumes

All 479 tests pass (full suite).

[vaab]

Heads up: a recent commit on master may already address this same problem from a different angle.

3bb5778 (fix: [overlay] flag NO SOUND only on stuck-at-rail, not on silence) replaced the variance-based dead-signal heuristic with a "stuck at the rail" detector: a frame is now treated as a dead device only when it is both flat and pinned near the i16 rail (|sample| ≈ 1.0). Benign silence — including the exact-zero digital silence that comes through during auto-pause — is flat but far from the rail, so it no longer trips the NO SOUND detector. That looks like it should break the auto-pause → dead-signal → resume → auto-pause oscillation this PR targets, without needing the explicit auto_paused guard.

If that's right, this PR's runtime fix would be redundant on current master (and it would also conflict, since it patches the now-removed frame_variance / DEAD_SIGNAL_VARIANCE_CEIL code).

@b0g — could you pull latest master and confirm whether the oscillation is gone on your setup? If it is, we can close this; if you can still reproduce it, let's keep it open and adapt the fix (and the regression tests) onto the new is_stuck_at_rail path. Leaving this open until we hear back from you.