Write down what starts the transmit pane again

Two things do, not one: the engine reporting the drop, and a new message
being keyed. The second was missing from the text, which is the fault the
last commit fixed.

The claim that the bridge does not forward MMTTY's window message 32772
is dropped. `docs/digital-bridge.md` argues the control cannot raise
`OnTranslateMessage` for a message it has an event for, `OnPttEvent` does
report drops here, and the two files disagreed. Says what is known and
what is not instead.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PdAYHcdRktqKry7nk414TU

docs/unfinished.md

@@ -71,7 +71,8 @@ typed into it, and a function key pressed meanwhile goes on the end of what is
 already waiting. Enter is a new line in the message. The message ends when the
 transmitter has been told to drop and the engine says it has: what went out is
 cleared off the pane, what was typed ahead is kept, and nothing goes out again
-until TX is pressed.
+until TX is pressed. A new message clears the pane the same way, for the case
+where two of them run close enough together that the transmitter never drops.
 
 `{RX}` runs when the message it stands in has been handed over, wherever it
 stands in the macro. Every other action macro runs before the text unless it
@@ -304,9 +305,32 @@ ignored. MMTTY reports the
 transmitter down at other times — the buffer hands it one character at a time
 and keeps it nearly empty — and taking that as the end cleared the pane and shut
 the gate two or three characters into a message, leaving the rest of it to go
-out on the next function key. N1MM does not read that report at all: it binds an
-empty handler to `OnPttEvent` and takes the transmit state from MMTTY's window
-message 32772 instead, which the bridge does not forward yet.
+out on the next function key.
+
+That report is not the only thing that starts the pane again, because it does
+not always come. Two macros pressed one after the other keep the transmitter up
+from the first to the last character, so the engine never reports a drop between
+them, and the pane kept both messages. Everything the engine has been given is
+locked — it cannot be taken back — so a run of macros left a pane with nothing
+in it that could be edited. `DigitalEngineSender.StartAsync` now calls
+`TypeAhead.Started` whenever it keys a new transmission, which drops the last
+message off the pane and keeps whatever was typed ahead.
+
+`TypeAhead.Ended` is called while the state lock is held, for the same reason.
+The drop arrives from the engine on a thread of its own, and a macro pressed on
+the last character of a message got as far as handing its own text over in the
+gap between reading the state and clearing the pane: the new text was wiped off
+the pane while the engine transmitted it. The order was found by reading the
+code, not on the air, and the fix has not been tested against a real engine.
+
+Which of the control's two paths carries the transmit state has not been
+settled. The bridge takes it from `OnPttEvent`, and N1MM's `DigitalInterface`
+binds an empty handler there and reads MMTTY's window message 32772 out of
+`OnTranslateMessage` instead. Both are in the same class, so one of them is a
+leftover, and `docs/digital-bridge.md` argues 32772 cannot reach
+`OnTranslateMessage` at all while the control has an event for it. `OnPttEvent`
+does report drops here, so nothing is missing; it is worth measuring only if the
+reports turn out to be coarser than the message.
 
 Keying is the keyer's, not the window's: `{TX}` and the TX button both go
 through `DigitalEngineSender.Transmit`, so the order to key is always the first