Apply operator clarifications: BOOTP, attract mode, PQS scope

- BOOTP was never actually implemented anywhere despite header
  mentions: removed it as a design consideration (pod addressing is
  static config); left a one-line "never implemented, don't design
  against it" note so it doesn't creep back in.
- No cockpit title has an attract mode - the games were never deployed
  as walk-up public arcade machines (Firestorm had unfinished plans
  for one). Corrected the TeslaRel410 deployment-goal wording.
- PQS reclassified from core bay component to support tooling: it is
  the operator's own event traffic-flow tool, not standard bay
  infrastructure. Kept as the natural seed for future cross-site
  queue/roster coordination (brainstorm shared-services table + open
  question reworded accordingly).

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

docs/BRAINSTORM.md

@@ -163,8 +163,6 @@ Fine between trusted operators, but do it deliberately:
   TCP/IP) via NetNub**, surfaced through NE2000-emulation bridged onto the bay LAN
   via pcap. Because it's plain IP with the emulated pod holding a real bay address,
   the routed-VPN model extends to them *in principle* unchanged.
-- Site-local pieces: BOOTP (broadcast) needs an answerer or static config per site —
-  same "provision locally, play routably" pattern as everything else.
 - Unknowns to test (cheap — emulator instances run on any PC, no cockpit needed):
   NetNub discovery/mesh addressing across subnets, and the latency tolerance of a
   30 Hz 1996 lockstep-era sim. Fold into the Phase 0 netem lab once the emulator
@@ -181,7 +179,7 @@ Fine between trusted operators, but do it deliberately:
 |---------|-------|
 | WireGuard hub | The rendezvous point; a VPS (could sit near the existing mysticmachines.com infra) or a box at the best-connected site |
 | Mumble | Cross-site voice day one — the FS507D release already integrated Mumble on the bay side. Channel per team, cross-team lobby channel |
-| Central PQS (event mode) | Cross-site events need one queue/roster. Options: (a) one central PQS all consoles poll — simplest, DB schema grows a `site` column; (b) per-site PQS + sync — only if WAN-down resilience of the local queue matters during events. Callsign uniqueness becomes fleet-wide (global registration table) |
+| Queue/roster coordination (future) | Cross-site events will want one queue/roster. **PQS** — the operator-built event traffic-flow tool — is the natural seed, but for now it stays support tooling. If promoted: (a) one central instance all consoles poll — simplest, DB schema grows a `site` column; (b) per-site instances + sync — only if WAN-down resilience of the local queue matters during events. Callsign uniqueness would become fleet-wide |
 | Neutral game host | Firestorm dedicated server for site-vs-site matches |
 | NTP | One clock for scores, logs, and replay/debrief alignment |
 | Fleet monitoring | VncThumbnailViewer pointed across the VPN; later, master-console status board |
@@ -220,7 +218,8 @@ worth a small design of its own later.
    degrade (rubber-banding, desync, disconnect)?
 5. **Dedicated Firestorm host** — does `mw4dedicatedui` build & run in the modern tree,
    and can camera/MR spectators join it cleanly?
-6. **PQS multi-site schema** — site column vs event database; global callsign policy.
+6. **PQS promotion** — if/when the event queue tool becomes cross-site coordination:
+   site column vs event database; global callsign policy.
 7. **Master-console arbitration** — what happens when site + master consoles command the
    same pod; do we need a soft lock ("bay is in fleet mode")?
 8. **Who hosts shared infra** — VPS vs best-connected site; bandwidth math for a

docs/PODBAY-ECOSYSTEM.md

@@ -9,7 +9,7 @@ A Pod Bay is **an air-gapped network of ~20 computers**:
 
 | Count | Machine | Software role |
 |------:|---------|---------------|
-| 1 | Command console | Operator station: TeslaConsole (pod management) + the game's console/lobby (Firestorm "BattleTech Console" ConLobby, or the era console for BT/RP) + PQS front-of-house |
+| 1 | Command console | Operator station: TeslaConsole (pod management) + the game's console/lobby (Firestorm "BattleTech Console" ConLobby, or the era console for BT/RP) |
 | 16 | Cockpit computers | Run the game exe in pod mode (`-ctcltype 2` for Firestorm) with cockpit I/O (RIO boards → RioJoy/VRio joystick layer) |
 | 1 | Live Cam station | Firestorm: game exe as camera ship (`-ctcltype 3`, `ctcl-camera.ini`) |
 | 1 | Mission Review station | Firestorm: `ctcl-mr.ini`; engine has a dedicated `MSRSpectator` project (`firestorm\Gameleap\code\mw4\Code\MSRSpectator`) |
@@ -125,19 +125,21 @@ the current Windows 10 cockpit hardware. Full plan: `TeslaRel410\emulator\PLAN.m
   rendering via OpenGL. The cockpit's real **RIO (COM1)** and **plasma display
   (COM2)** are passed through to physical serial ports so the game's own 1996
   drivers run the actual cockpit hardware; SB16 emulation feeds the speakers.
-- **Ultimate goal:** deploy to the current pods — power-on → attract mode, playable
-  in the cockpit (plan estimates ~3–5 months focused work; gauges deferred).
+- **Ultimate goal:** deploy to the current pods — power-on boots straight into the
+  game, playable in the cockpit (plan estimates ~3–5 months focused work; gauges
+  deferred). *Note: none of the cockpit software has an attract mode — these titles
+  were never deployed as walk-up public arcade machines. Firestorm had plans for
+  one, never finished.*
 - **Networking — the SiteLink-relevant part:** the original pods networked over
-  Ethernet using **WATTCP (DOS TCP/IP, with BOOTP) via VWE's NetNub layer**
-  (`CODE\*\MUNGA_L4\NETNUB\`). The emulator exposes this through **NE2000 emulation
-  bridged via pcap** — i.e. the emulated game gets a real presence on the bay LAN
-  with its own MAC/IP. Consequences:
+  Ethernet using **WATTCP (DOS TCP/IP) via VWE's NetNub layer**
+  (`CODE\*\MUNGA_L4\NETNUB\`). Pod addressing is static configuration. (BOOTP
+  appears in a few WATTCP headers but was never actually implemented anywhere —
+  don't design against it.) The emulator exposes the stack through **NE2000
+  emulation bridged via pcap** — i.e. the emulated game gets a real presence on the
+  bay LAN with its own MAC/IP. Consequences:
   1. It's plain IP — in principle it routes across a SiteLink VPN like any other
      bay host (an emulated pod could be a `10.0.y.x` address).
-  2. **BOOTP is broadcast** — the boot-time address assignment is site-local; each
-     site needs its own BOOTP answerer (or static WATTCP config). Same pattern as
-     SecureConfig beacons: provisioning local, play routable.
-  3. Pod-to-pod/console addressing inside NetNub (discovery, mesh formation,
+  2. Pod-to-pod/console addressing inside NetNub (discovery, mesh formation,
      latency assumptions of a 30 Hz 1996 sim) is unverified for cross-subnet play —
      open question, testable cheaply since emulator instances run on any PC.
 - **Relationship to BT411/RP411:** two complementary strategies for the same
@@ -145,16 +147,15 @@ the current Windows 10 cockpit hardware. Full plan: `TeslaRel410\emulator\PLAN.m
   faithful emulation (TeslaRel410, original binaries, original protocols). SiteLink
   should assume *both* may want cross-site play eventually.
 
-### PQS — Pod Queue System (front of house)
-- XAMPP (Apache/PHP/MySQL) app: registration, callsigns, combined queue displays,
-  history/search (`PQS\*.php`).
-- The game/console side **polls simple HTTP endpoints**: `getFSgame.php` prints the next
-  mission's game type/map/16 condition flags; `getFSplayers.php` the roster. MySQL db
-  `pqs`, tables `pqs_gameconfig`, `pqs_queue`, `pqs_mission`.
-- Single-site by construction today (localhost MySQL, one queue). Multi-site play needs
-  either a shared central PQS or per-site PQS with an event/sync mode.
-
 ### Support tooling
+- **PQS — Pod Queue System** (`C:\VWE\PQS`): operator-built event tooling — developed
+  by the pod owner to manage traffic flow when bringing pods to events, not part of
+  the standard bay network. XAMPP (Apache/PHP/MySQL): registration, callsigns,
+  combined queue displays, history/search. The game/console side polls simple HTTP
+  endpoints (`getFSgame.php` = next mission's type/map/condition flags;
+  `getFSplayers.php` = roster; MySQL db `pqs`). **SiteLink scope: support tooling for
+  now** — but it's the natural seed if cross-site queue/roster coordination is wanted
+  later.
 - **VncThumbnailViewer** (`C:\VWE\VncThumbnailViewer`): operator monitoring of pod
   screens — works fine across a VPN, and a master console could reuse it for fleet-wide
   eyes-on.
@@ -174,7 +175,7 @@ the current Windows 10 cockpit hardware. Full plan: `TeslaRel410\emulator\PLAN.m
 | 1501 | TCP | console → pod | Munga game control (RP; BT411 uses same convention, port per `-net`) |
 | 1000 / 1001 | TCP/UDP (unverified) | console ↔ launcher/game/camera | CTCL control channel (`PORT_Launcher`/`PORT_Game`/`PORT_CameraShip` in `firestorm\...\Launcher\ctcl.cpp`) |
 | 47624 + 2300–2400, or fixed `DirectPlayPort` | TCP/UDP | pod ↔ session host | Firestorm DirectPlay 4 session + game traffic |
-| 80 | TCP | console/game → PQS box | PQS HTTP endpoints |
-| 3306 | TCP | PQS internal | MySQL (localhost today) |
+| 80 | TCP | console/game → PQS box | PQS HTTP endpoints (event tooling, when deployed) |
+| 3306 | TCP | PQS internal | MySQL (localhost) |
 | 64738 | TCP/UDP | all → voice server | Mumble (2016 release convention) |
 | 5900 | TCP | operator → pods | VNC monitoring (optional) |