Feature request: native file/path watch primitive (Claude Code Monitor() equivalent)

Summary

jcode has no first-class primitive equivalent to Claude Code's Monitor() tool: watch a filesystem path (or process/log) and automatically inject change events into the conversation as they happen, without the agent having to poll.

What exists today (and why it's not equivalent)

• bg (watch/subscribe/delivery) monitors background tasks the agent itself started — it wakes/notifies on task completion or checkpoints, not on arbitrary file mtime/content changes.
• ScheduleWakeup lets an agent schedule itself to wake up after a delay and re-run a prompt. This can approximate a watcher (wake every N seconds, stat/diff a file, react if changed), but it's the agent hand-rolling a poll loop every time, not a reusable primitive — no debouncing, no diff-on-change payload, no clean "stop watching" lifecycle, and it burns a scheduled wakeup slot per file per session.

Requested capability

A watch_file (or similar) tool/primitive that:

• Takes a path (file or directory, optionally recursive) to watch, likely backed by FSEvents/kqueue on macOS and inotify on Linux, rather than polling
• Delivers change events (created/modified/deleted, ideally with a diff or new-content snippet) as part of the agent's next turn — analogous to how bg's wake/notify delivery already works for background tasks
• Supports start/stop/list, similar to the existing bg lifecycle actions
• Optional debounce interval to avoid flooding turns on rapid successive writes (e.g. log files, build output)

Use case that surfaced this

Coordinating on a task where the natural pattern was "watch this file/log and tell me when it changes" (mirroring a Claude Code workflow the user already relies on) — currently the only way to do this in jcode is to hand-build a poll loop with bg/ScheduleWakeup, which works but isn't a real primitive and doesn't compose well across sessions/swarm workers.

Non-goals / scope note

This is a feature request, not a bug report — happy to help scope further (e.g. should this live in the bg tool as a new watch-source type, or be its own tool) if useful.

Start by reading the existing bg watch/subscribe/delivery lifecycle and ScheduleWakeup behavior described in the issue. Determine whether file watching belongs in bg or as a separate tool, then define the event, debounce, and start/stop/list behavior; done requires an agreed design and implementation scope, since no files or tests are named.