feat(triggers): a meet trigger whose semantics are a meeting

[RatulMaharaj]

Closes the trigger half of #190. Now based on main, since the previous six merged.

Why not just use tty

An agent joins a meeting over tty today, and docs/tty.mdx states its contract:

Each connection is a conversation.

That is right for a terminal, where a new window should be a fresh start, and backwards for a meeting. The meeting is the conversation; connections come and go inside it while a laptop sleeps, a bridge reconnects, or a second client attaches.

The transport is not the problem, so this keeps it. WebSocket is right here: bidirectional, long-lived, and the frames are already JSON. Streaming HTTP would be worse, since SSE is one-directional and input would need a second connection with its own lifetime. Media stays the bridge's job. What changes is what a connection means.

What is different from tty

join is required and carries the meeting id. The key is meet:<meeting_id>. A connection that never names a meeting is refused rather than handed an invented one, so #189's failure mode cannot occur here by construction rather than by warning.

participant records who came and went without spending a turn. A busy room would otherwise start a run per arrival.

end is distinct from the socket closing, and it is the frame that earns the trigger. Today a closed socket is ambiguous between a dropped connection and a finished meeting, and the agent cannot tell which, so it can never reliably write the record. end says which happened while the conversation is still in context.

summarize_on_end is opt-in:

triggers:
  - type: meet
    token_env: MEET_TOKEN
    summarize_on_end: |
      The meeting is over. Write the record: what was decided,
      what is still open, and who owns what.

Set it and end spends one more turn; the reply comes back as {type: "summary", text} and lands in the transcript, which is the record that outlives the meeting and the thing #173 needs. Leave it out and an ending costs no model call, because a summary per meeting is not something every agent wants.

What stays the same

tty is untouched and remains a terminal. The genuinely shared pieces (image validation, the constant-time token compare) moved to ws_session.ts with no behaviour change; the tty tests still pass unmodified.

Testing

515 pass, deno task ok clean. Eight new, each pinning a way this differs from a terminal:

• nothing runs before join, and an empty meeting_id is refused
• a reconnect to the same meeting resumes the same conversation, asserted against the stored transcript rather than a frame
• two meetings do not share a conversation
• end writes the record, and the summary is in the transcript rather than only on the wire
• without summarize_on_end, an ending adds no messages and sends no summary
• participant frames add no turns, and a malformed one errors
• unauthorized upgrades refused before any frame
• triggersFromConfig builds it and names a missing token env var

What is not done

report_to. An agent can schedule follow-up work during a meeting; the schedule survives restarts and the work runs. When it fires after the meeting there is no open socket, deliver returns false, and AgentService.#deliver falls back to a logInfo truncated at 200 characters. Routing that to another trigger is a service-level concern rather than a trigger one, so it is still open on #190.

A meeting that ends without an end frame. If a bridge cannot always tell that a meeting finished, the record never gets written. Documented rather than papered over, and it is the first question I asked the bridge side to answer.

The bridge side is being written in parallel against this frame vocabulary.