iris
6236f0d5bd
Peer messages were only ever produced by the *import* path, reading them out of the CLI's own session file. A message another agent sent to a session this server was driving appeared nowhere, so the session started working on something nobody on the phone had asked for and there was nothing on screen to explain it. Measured rather than guessed, because the obvious place to look for it is empty: a real cross-session message sent to a real `--input-format stream-json` session on CLI 2.1.237 produces **no `user` record**, and nothing in the partial-message stream mentions it either. The whole of it arrives as an `origin` object on the turn's `result`, in exactly the shape the session file records -- so `import::peer_message` now reads both, one function for one wire format. Two copies would drift the first time a field is renamed, and the half that drifted would go on producing nothing, which is indistinguishable from nobody having sent anything. The cost is the position: the note lands after the reply it caused rather than above it, because at no earlier point in the turn does the CLI say why the turn started. Taken deliberately over the alternative -- a second reader tailing the CLI's own session file for the one record stdout does not carry, which is two sources of truth for one conversation and a poll per live session. Recorded in PLAN.md so that if the CLI ever announces the injection where it happens, the next reader knows to move it there. Both halves tested: the real record shape, and an ordinary result carrying no `origin` -- which is the half that decides whether the check is a check. Four ordinary results on a real session's stdout had none between them.