operator-console KB: record what survives of the 1995 console (BTCNSL.CPP message defs; the Macintosh clue)

The changelog line in game/original/BT/BTCNSL.CPP -- '06/03/95 GAH Added
corresponding Macintosh message definitions' -- implies the 1995 sysop station
was a Mac application in a separate codebase, which explains its total absence
from the pod-side archives.  Recorded so the provenance question ('is our
console a port or a recreation?') has a durable answer: wire-faithful
recreation, from the surviving parser side.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

context/operator-console.md

@@ -16,6 +16,17 @@ open_questions:
 The system-operator station: build a mission, run a session, watch pods arrive, launch rounds.
 This is the piece the 1995 archive lost and we rebuilt.
 
+**What survives of the original, and why so little:** the console APPLICATION is absent from every
+archive (and Route A is closed). What we have is the pod's half of the conversation --
+`game/original/BT/BTCNSL.CPP` (orig. `cnslmsgs.cpp`, one of the ~10 surviving BT game `.cpp`),
+defining the Console* messages the game sends TO the console (MechKilled / MechDamaged /
+ScoreUpdate / TeamScoreUpdate / DeathWithoutHonor / EndMission) -- plus the engine's receive-side
+handlers (egg / RunMission / StopMission).  Its changelog line *"06/03/95 GAH -- Added
+corresponding Macintosh message definitions"* implies the 1995 sysop station was a **Macintosh
+application**, a separate codebase that was never in the pod build tree -- which is why no archive
+has it.  `btconsole.py`/`btoperator.py` are therefore a wire-faithful RECREATION built from the
+surviving parser side (+ BT_NET_PROBE against the real exe), not a port of the lost program.
+
 > **Sysop-facing instructions live in `docs/OPERATOR_GUIDE.md`.** This file is the
 > engineering description — how it is built and where it breaks.