Review the Section 4.1-4.4 implementation of feishu-bridge-bg-tasks.

Scope: BgSupervisor skeleton + UDS listener + 1s fallback poller + CAS launcher.

Focus areas (report PASS/WARN/BLOCK with file:line):
1. Concurrency: listener thread + poller thread both call DAO; CAS claim vs list_queued_for_launch — any TOCTOU or double-spawn risk?
2. Stale socket handling: probe → unlink → rebind race window (peer could bind between unlink and our rebind).
3. stop() correctness: partial start() failure cleanup; sqlite3 conns closed; listener fd closed; no thread leak.
4. Popen exception handling: set_state_guarded rollback — what if row no longer in 'launching' (someone flipped it)? Is the inner try/except too broad?
5. Cancel SLO: _flip_cancel_requested_queued uses raw SELECT — is reading repo.conn directly consistent with the repo's transaction contract?
6. Socket permissions: chmod 0600 ordering — between bind() and listen(), there's a tiny window where mode isn't 0600. Attack?
7. Spec adherence vs .specs/changes/feishu-bridge-bg-tasks/design.md §UDS Wake Protocol and §Cancel SLO.
8. Test coverage gaps in tests/unit/test_bg_supervisor.py.
9. Integration block in feishu_bridge/main.py — try/except Exception swallowing too broad?

Files:
- feishu_bridge/bg_supervisor.py (new, 434 lines)
- tests/unit/test_bg_supervisor.py (new, 19 tests)
- feishu_bridge/main.py (modified, supervisor boot block before ws_client.start())

Reference (don't edit):
- feishu_bridge/bg_tasks_db.py — DAO (claim_queued_cas at line 716, set_state_guarded line 733)
- .specs/changes/feishu-bridge-bg-tasks/design.md
- .specs/changes/feishu-bridge-bg-tasks/tasks.md

Return concise actionable findings. Section 4.5 (delivery watcher) is deferred — _scan_delivery_outbox is a seam.
