Recover screen-recording indicator after stuck probes

[fresh3nough]

Summary

Fixes #9205.

ScreenRecording.qml polls with a one-shot Process (pgrep). refresh() returns early while statusProc.running is true. If onExited never fires cleanly (abrupt recorder kill, handler glitch, etc.), that flag stays true forever — no further probes run and the bar icon freezes on "recording" even when no gpu-screen-recorder process exists. Workaround was omarchy restart shell.

Change

• Arm a 2s watchdog when a probe starts; if still running, force statusProc.running = false and refresh again.
• Add a 2s poll timer so kills that skip omarchy-capture-screenrecording's indicator toggle still update the bar.

Test plan

• Static contract: watchdog + poll + stuck-clear path present
• Existing screenrecording-test.sh still passes
• Verified on GCP VM

./test/shell.d/screenrecording-indicator-test.sh
./test/shell.d/screenrecording-test.sh

[omarchybot]

I reviewed this at 97822ab against quattro and read it alongside #12471, which fixes the same issue (#9205) a different way. I didn't run it on a worker, because I'm not recommending it as the fix to carry forward. That choice is the maintainer's, so this waits on them.

What leaves the indicator stuck. The stuck-probe explanation doesn't hold as far as I can see. statusProc runs pgrep, which exits in milliseconds whether or not gpu-screen-recorder died abruptly. The recorder isn't the probe's child, so its death can't keep statusProc.running true. The issue comment from @ReneXiong traces a cause in bin/omarchy-capture-screenrecording instead:

• stop_screenrecording refreshes the indicator before the SIGKILL fallback, while the recorder is still alive.
• --stop-recording with no recorder running exits 1 without refreshing, so clicking the stale icon never heals it.

The reporter's repro (killing the recorder directly) also leaves nothing to call a refresh. #12471 fixes both script paths, event-driven, and was reproduced and verified on a disposable Omarchy VM.

What this PR adds. The 2s watchdog targets a probe that never exits, and I found no evidence that happens. The always-on 2s pollTimer is what would actually unstick the icon. But it spawns a pgrep every two seconds for each bar (one per monitor) for the life of the session, and no other indicator in shell/plugins/bar/indicators/ polls. The new test greps for this PR's own identifiers (probeWatchdog, pollTimer, interval: 2000), so it passes whenever the code is present and can't show the bug is fixed.

What only this PR would cover. If the recorder dies on its own mid-recording, nothing calls a refresh. With #12471 the icon stays "recording" until it is clicked, and the click then clears it. With this PR's poll it clears within two seconds. The same poll would also mask #10311 (stuck "active" after a restart on two monitors), whose cause isn't known yet. If the maintainer wants a poll for that, it is a design decision separate from #9205.

Second opinion. None. The configured reviewer (Codex Medium) answered a ping, but today's review budget was spent when I asked it to compare the two PRs, so this is one model's reading.