Handle returned by subscribe_file/subscribe_dir. Holding this alive
is not required (unlike the raw notify::Watcher, which must be kept
alive by its owner) — the pool itself owns the underlying watcher.
unsubscribe takes this by value so a caller can’t accidentally
unsubscribe the same handle twice.
Broadcast channel capacity. Generous relative to real fs-event volume
(file-save bursts, not high-frequency streams) — a slow consumer would
need to fall behind by this many raw events before RecvError::Lagged,
at which point it should resync from scratch rather than assume it saw
everything (same “wake signal, not a guaranteed delivery log” contract
the existing three watchers already have via their own debounce logic).
Build the watcher backend: prefer the native OS backend
(inotify/FSEvents/ReadDirectoryChangesW); fall back to notify‘s
stat-based PollWatcher if the native backend can’t even construct
(practically never on the platforms AgentMux ships for, but real on some
restricted/containerized environments). Returns (None, Native) only if
both fail to construct — recorded as WatchBackend::Native since that
was the attempted backend; every subscribe_* call will immediately
fail into degraded_paths until the process restarts, matching the
existing three watchers’ “live-update becomes unavailable, nothing else
breaks” posture, just now with a health signal instead of silence.