fix(watcher): degrade to slow probes after repeated native watcher failures

[devswha]

What

Fixes #42. The native session watcher supervisor retried every 30s forever when its child could not stay up. Under inotify exhaustion (ENOSPC) that produced 1752 consecutive silent failures over 14.5 hours, with discovery updates degraded the whole time and nothing actionable in the log.

How

• After 20 consecutive failures the restart schedule degrades from the fast exponential backoff (1s→30s) to a 10-minute probe cadence: recovery stays automatic when the host condition clears, without a permanent 30s crash loop.
• Crossing the cap logs one loud line naming the run length — and when the child's stderr contained the ENOSPC token, the exact remedy (fs.inotify.max_user_watches). Only that fixed token is retained; stderr content itself is still never forwarded, preserving the invariant that watcher diagnostics never expose transcript paths.
• The chokidar per-provider watchers append the same remedy hint to their existing error line when the error names ENOSPC.
• getGjcWatcherHealth() exposes ok/consecutiveFailures/degraded/enospcObserved for status surfaces; the restart schedule is a pure exported function under regression tests.

The client-visible degraded-discovery banner suggested in #42 is a UI contract change and stays open for follow-up; this PR removes the silent infinite loop and makes the failure diagnosable and self-recovering.

Verification

• gjc-session-watcher.test.ts: ENOSPC token detection without leaking stderr content (path-bearing stderr never surfaces).
• sessions-watcher-degrade.test.ts: fast backoff below the cap (1s,2s,4s,…,30s), degraded 10-min probes at/after the cap (incl. failure 1752), health shape.
• Full suite: server 930 + client 262, 0 fail. typecheck + eslint clean.