fix(drive): emit watch events as single-line NDJSON in json mode

[yurenju]

What

drive watch --json now emits each event as a single line of NDJSON instead of a multi-line pretty-printed JSON object.

Why

In --json mode the watch loop rendered events with JSON.stringify(data, null, 2), producing events that span many lines. A drive_sync_once event lists every path in the library (including unchanged files), so for a large synced folder a single event easily exceeds any line-oriented reassembly buffer on the consumer side.

The WSPC Drive desktop app reassembles these multi-line events with a 64KB buffer. When an event blew past that cap, the app dropped it, its sync badge froze on "Syncing…" forever, and the corrupted buffer went on to swallow every subsequent event for that binding (including realtime reconnect notices). This was reproduced from the app's events.log: a large drive_sync_once split into cli output: { / "action": "upload_create" fragments, after which that binding produced no further log lines.

Single-line NDJSON removes the multi-line reassembly problem at the source: consumers parse line by line, and no per-event size assumption can wedge the stream.

Notes for reviewer

• Pretty (non-json) output is unchanged — still goes through render().
• shouldOutputJson() is now exported from output/render.ts so the watch command can branch on the same output-mode logic the renderer uses.
• New test asserts every write in json mode is a single newline-terminated, individually-parseable JSON line.
• The companion app-side fix (assembler self-healing + resume handling) will come in a separate WSPC Drive PR after this is released and the bundled CLI is bumped.