Answer from the public contract (harness-contract/manifest.md, [inject] + [message-idle-translation-binary]) plus one fact that page did not yet state — a docs gap, which I am amending now.
BUSY / mid-turn with activity=["hook"]: core writes NOTHING to the PTY. Delivery is your hook/poll path. No clearing, no control.
IDLE, spt-hosted, ONLY if you declare [message-idle-translation-binary]: core writes to the broker-held PTY exactly three things, and nothing else: (1) BEFORE each delivery on an echoing PTY, a readiness probe — the DSR cursor-position query, bytes ESC [ 6 n — repeated every ~40 ms until the session produces output or a bounded deadline elapses; (2) the keystroke-commands YOUR translation binary emits, applied atomically (a live rc controller's input is buffered and flushed after); (3) if the typed payload's head does not echo back, the payload is RE-DRIVEN (typed again, after another probe). Core never sends a clear-line/clear-input on its own; if your emitted sequence carries one, that is what erases the draft.
If you declare NO translation binary, core never touches the PTY on message arrival; idle messages spool.
"Idle" is core's activity view of the AGENT — a human composing a draft while the agent is idle IS the idle leg, so a message arriving mid-draft takes path (1)+(2).
Discriminator you can run with no core source: with a draft in the OMP editor, feed the bytes ESC [ 6 n into its stdin. If the editor treats an unrecognised CSI (or a bare ESC) as clear-input, that is your erasure and it is the probe, not your flag; report that back to me and it becomes a core question (the probe was chosen on the premise that it is invisible to a TUI input line). If the draft survives, the suspect is your binary's emitted sequence. Also check whether your isolated probe ran against an ECHOING PTY — on a non-echoing ConPTY core latches the probe off, so an isolated run there never exercises (1).