A move made in the terminal never reaches an open browser tab live #56

Follow-up from review on #36 (item 5): the live-update bus (src/bus.ts) is in-process, and src/tty.ts runs as a separate process against the same SQLite file, so a card moved, added, or deleted from the terminal reaches no open /events stream — a web tab only sees it on its next full page load. This is already named as a known limitation in the README ("What's simulated" and the Live section), but the two doors (web and terminal) behaving alike is the bar the app sets for itself elsewhere, so this tracks actually closing the gap.

Two directions worth considering:

• Have the terminal process publish onto the same bus by making it another writer against the app process (not straightforward across two OS processes with today's in-memory bus).
• A change counter or last_modified column the web process polls cheaply, so a terminal-side write is picked up within a second the same way a browser-side one is today.

Not urgent — no user-facing report has asked for it — but worth deciding on and scoping before it grows.

Closing as a duplicate of #31, which is the same gap filed from the other side of the same review — not because the finding is wrong. It is right, and it is the last piece of the direction's own sentence.

#31 ("A move made in the terminal reaches the open web pages too") names the second of the two options here and says how to build it: src/tty.ts cannot call into the server process's bus, so the server watches a per-board revision in the shared SQLite file — the same boardRevision #17 is adding for the mirror-image case — polls it about twice a second only for boards that have an open listener, and publishes with by: null so no tab mistakes it for its own optimistic write. It carries a checklist and a test shape (drive a write from a second process, assert the stream emits).

That is why this one reads as ready while #31 reads as blocked: #31 waits for #17 (pull #47), which brings the revision counter. Building the polling loop before that lands means inventing a second counter and then deleting it.

The first option here — making the terminal a writer on the in-process bus — is worth one line in #31 as the road not taken: it means a socket or a second channel between two OS processes, which is a dependency-shaped change in an app that has none, for a case a cheap read of a number already covers.

Nothing is lost: #31 stays open, blocked by #17, and it is the issue to pick up the moment pull #47 merges.

Correction to the comment above: I cannot close this — the forge answers forbidden when I patch an issue I did not open — so it stays open until someone with the scope closes it. Everything else in that comment stands: #31 is the live issue for this gap, it carries the checklist and the test shape, and it waits on #17 (pull #47) for the revision counter this needs.

So that nothing picks this up ahead of that work, I have marked it as waiting for #17 as well. Treat #31 as the one to build and this as its duplicate.

Closing: #31 is done — src/watch.ts polls boardRevision (from #17/pull #47, now on main) for every board with an open listener and publishes an external event with by: null when it moves without this process having published it itself. A move made in src/tty.ts now reaches an open /b/:id page within a second, same as a live edit from another tab.