Reintroduce monitors/ as a proper long-running streaming daemon

[ZaxShen]

Context

monitors/monitors.json was removed in commit $(git -C /Users/Zax/Git/GitHub/TMB/plugin log -1 --format=%H monitors/ 2>/dev/null || echo 'recent commit on docs/40-dogfood-scenarios') because CC's monitor subsystem reported our one-shot poller's exit as "Monitor stream ended" every tick, which looked like a failure during live dogfood runs.

What was there

• monitors/tmb-trajectory-events.js — one-shot: reads new rows from the SQLite `ledger` table, prints any `task_failed / escalation / retry_exhausted` rows, exits 0.
• monitors/monitors.json — pointed CC at the script with `"when": "always"` (unverified semantics).

What we actually want

A live status-line / notification feed that:

• Opens one long-lived readonly sqlite connection.
• Polls (or uses filesystem watchers) for new `ledger` rows.
• Streams events to CC's notification channel as they arrive, without terminating.
• Handles DB-not-yet-created gracefully (waits until first `issue_create`).
• Respects `TRAJECTORY_DB_PATH` env override.

Acceptance criteria

• Study the CC monitor subsystem's actual contract (what `when` values exist, what streaming behavior triggers the "stream ended" message, whether multiple messages can be emitted over the lifetime of one process).
• Rewrite `tmb-trajectory-events.js` as a long-running process.
• Reintroduce `monitors.json` with the correct `when` value.
• Verify live in a dogfood session: failed tasks emit notifications; idle sessions emit nothing; the "stream ended" message does NOT appear under normal operation.

Related

• PR $(gh -R trustmybot/plugin pr list --state open --head docs/40-dogfood-scenarios --json number --jq '.[0].number' 2>/dev/null) removed the config; the .js script + package.json remain in the tree for revival.

[ZaxShen]

Closing as wontfix per current doctrine. monitors/ was deleted in v0.3.0 (commit 8368536) with the rationale: "orphan code never wired into any plugin manifest". The 'long-running streaming daemon' design proposed here was never specced in CC's plugin-manifest schema; CC ships its own status-line / notification surface and we shouldn't shadow it. The trajectory DB is queryable via MCP at any time for the same data this would have surfaced. Reopen with a concrete CC monitor-subsystem contract if the situation changes.