A write from the terminal reaches the page live: one event bus across processes #9

src/live.ts says it plainly today — "the bus is this process's: the terminal is another process, and its writes show on the next load rather than live" — but AGENTS.md asks that a write made at the terminal reach web viewers live like any other. Close that gap before there are votes to miss.

What done looks like

• A migration appends event (id INTEGER PRIMARY KEY, type TEXT NOT NULL, data TEXT NOT NULL, created_at TEXT NOT NULL DEFAULT (strftime(...))) — a plain table, no new dependency.
• emit(type, data) writes the row and still notifies in-process listeners immediately, so a page served by this process sees no added latency. The function's signature does not change, so no action has to be edited.
• GET /events streams from the table: a client that connects with Last-Event-ID (or ?since=) gets what it missed from the row store rather than the in-memory ring, so a reconnect after a restart still catches up.
• The server follows rows written by another process — a tick no slower than 500ms that reads SELECT * FROM event WHERE id > ? with the highest id it has sent, and nothing more when there is nothing new. The page still polls nothing; only the server does, over a local SQLite read.
• Rows are trimmed: nothing older than an hour and no more than 1000 rows survive, trimmed after a response rather than inside one.
• src/tty.ts needs no new concept: because it calls the same actions and the same emit, its writes now arrive at open pages. A test proves it — write through an action on a second Database handle to the same file, and see the event arrive on a /events stream served by the first.
• Ids stay monotonic across restarts (the table's rowid is the event id), and a client that reconnects with an id from before a restart is not sent the whole history twice.
• src/live.test.ts covers: an event emitted in-process reaches a subscriber; an event written by another connection reaches the stream within a tick; since replays only what follows; the trim keeps the newest and drops the oldest; a closed stream unsubscribes and stops the tick's work.
• README.md drops the sentence that says the terminal's writes are one reload behind, and bun test is green.

Files I expect to change: src/live.ts, src/live.test.ts (new), src/db.ts, src/server.ts (starting and stopping the follower), README.md.

Risks: the tick is the one thing here that runs forever — give it a single timer for the whole process, not one per connection, and stop it when the last stream closes. Serialize data as JSON at the boundary and parse it once on the way out; a row that will not parse is skipped, never thrown. Keep the common request under 50ms: the follower's query is indexed by the primary key and asks for nothing when the highest id has not moved. Issue #2 also appends a migration — whichever lands second appends after the other and edits nothing that has run.

Fit: Hearth — a supervisor, a stream, and an honest statement of what is live. A person assigns; I do not.