Feat(tasks): zn task watch prints each task status change as it happens

[adibhanna]

For ZenNotes/zennotes#941: a script should be able to react when a task changes status (for example, start an agent when its card moves from Backlog to Ready) without ZenNotes running commands itself.

What it adds

• zn task watch prints one line per task whose status changes: note path, title, task text, previous and new status. With --json each line is one JSON object:

  {"at":"2026-10-14T15:47:24Z","id":"inbox/Parser.md#task","path":"inbox/Parser.md","link":"zennotes://open?path=inbox/Parser.md","title":"Parser","kind":"file","content":"Parser","previousStatus":"backlog","status":"ready","lineNumber":0}

• zn task list --json now carries each task's status (a task note's status:, a line's @status:, or the note's status a line inherits). Content and ids are unchanged. zn mcp's list_tasks uses the same grammar and gains the key too; its description now names the field, and its status argument says it filters by state (open, done, waiting), not by that column. The desktop's own MCP server gets the same field and words in Feat(mcp): list_tasks says which status column each task is in, as zn mcp does zennotes#943.

How a status is read

As the Kanban board shows it. A task note's status is its frontmatter status: (open when it has none). A checkbox line is done, cancelled or forwarded once its box says so, since a board grouped by status drops those cards; until then it is its @status: or its note's status, and otherwise waiting, in-progress or open.

Tasks are matched between scans by note and words, not position, so adding a task above another, editing a task's words or saving without a status change prints nothing. Tasks that appear or disappear are not reported. The watch remembers each task's last status, so a task one scan misses (a note read while an editor rewrites it in place, or a file a sync tool replaces) that comes back with another status is still reported, once.

Where changes come from

• Local vault: the terminal app's file watcher, moved from internal/tui to internal/fswatch so both use it (names exported, behavior unchanged).
• Server: changes pushed over /api/watch. While that stream is unavailable (an older server, a proxy without WebSockets) the server is asked every --interval seconds (default 5), and the stream is retried every 30 seconds.
• A failed scan is reported (as JSON on stderr with --json) and the watch continues. Ctrl-C exits 0, as zn server run does.

Verification

• go vet ./... and go test ./... pass; the watch tests also pass under -race -count=5.
• On Linux (a cross-compiled test binary on an Ubuntu box), the watch tests pass 300 times in a row. The first CI run here failed: the JSON-lines test assumed an order, and a scan that read a note mid-rewrite lost a change. 58b0e56 fixes both; before it, the test failed 54 times in 100 there.
• Built binary on a scratch vault: an atomic save (temp file plus rename), an in-place edit and zn task toggle each printed one line, a body-only save printed none, and Ctrl-C exited 0.
• Desktop app driven over CDP with an isolated profile: on the Kanban board grouped by custom status, dragging a task note from Backlog to Ready and a checkbox task from Backlog to Review printed exactly those two lines.

How to test locally

go build -o ./zn ./cmd/zn
mkdir -p /tmp/zn-watch-vault/inbox
printf -- '---\ntags: [task]\nstatus: backlog\n---\nInstructions.\n' > /tmp/zn-watch-vault/inbox/Parser.md
./zn task watch --vault /tmp/zn-watch-vault

In another terminal:

sed -i '' 's/status: backlog/status: ready/' /tmp/zn-watch-vault/inbox/Parser.md

The watch prints backlog → ready Parser inbox/Parser.md. Editing only the body prints nothing, and --json gives the line above. Opening the same folder in the desktop app (Tasks, Kanban, Group by Custom status) and dragging the card works the same way.

Follow-ups (not in this PR)

• After a zn release: bump the desktop's bundled zn pin, and document zn task watch in the in-app help and on zennotes.org.
• The desktop's own MCP server reports status in Feat(mcp): list_tasks says which status column each task is in, as zn mcp does zennotes#943.