SiteConfigMerge tool + operating-model updates from operator input

New: tools/SiteConfigMerge (net48 console app)
- dump: decode any .siteconfig (squads, pods, IPs, MACs, host types)
- merge: combine <siteName>.siteconfig inputs into master.siteconfig,
  renaming squads "<siteName>-<original squad name>"
- Pod records pass through byte-for-byte; only squad records (the
  rename) are re-serialized, under the TeslaConsole assembly identity
  captured from the input. Stand-in types + SerializationBinder, so no
  build dependency on TeslaSuite.
- Warns on duplicate pod GUID/MAC and cross-site IP overlap.
- Verified end-to-end: the real TeslaConsole.exe 4.11.4.1 loaded the
  merged master via its own Site.LoadFromFile (reflection harness).

Doc updates from operator decisions:
- Operating model settled: sites voluntarily hand console authority to
  the central console for the duration of a SiteLink event, by
  contributing their siteconfig. Federation ruled out at current scale.
- Siteconfig "secrets" framing corrected: pod keys have no practical
  value outside the air-gapped bay; files are exchanged per event and
  never stored in this repo (tools only).
- Fleet scale recorded: 6 active pod bays, <120 cockpits in existence;
  bay sizes range console+2 cockpits up to the full 20-node complement.
  Open question 9 answered.
- Hub hosting direction: neutral Firestorm host at the WireGuard hub;
  the FS server usually IS the Live Cam, so stream its output to all
  sites and optionally to the public internet. Mission Review instance
  runs at the hub too - one authoritative debrief streamed everywhere.
- Virtual PDF scoresheet printer at the hub: event debriefings print
  centrally, retrievable from any site on the link.
- Voice (Mumble) backburnered - revisit only on event interest.
- .gitignore: build outputs; siteconfig exclusion rationale reworded.

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

docs/PODBAY-ECOSYSTEM.md

@@ -3,9 +3,13 @@
 Surveyed 2026-07-10 from the sibling repos under `C:\VWE`. Every claim below has a source
 pointer so it can be re-verified as those repos evolve.
 
-## 1. Physical bay composition
+## 1. Physical bay composition and fleet scale
 
-A Pod Bay is **an air-gapped network of ~20 computers**:
+A Pod Bay is **an air-gapped network of up to ~20 computers**. Sizes vary widely:
+the smallest active bay is a console + 2 cockpits; the full complement is below.
+Fleet scale (2026): **fewer than 120 cockpits left in existence, 6 currently active
+pod bays** — every design choice in SiteLink should assume single-digit sites and
+a ~120-seat ceiling.
 
 | Count | Machine | Software role |
 |------:|---------|---------------|
@@ -41,11 +45,19 @@ machines on the internet.
   `TeslaConsole.Squad` (mGuid, mName, mOnline) → `TeslaConsole.Pod` records:
   `mId, mIPAddress, mGateway, mDns, mSubnet, mHostName, mKey, mMacAddress, mName,
   mPodArtPath, mHostType, mOnline`. Two consequences for SiteLink:
-  1. "Concatenating" siteconfigs = a real deserialize/merge/reserialize tool (or native
-     multi-site support in TeslaConsole — buildable, since the console is now rebuilt
-     from source). The `Squad` concept maps naturally to "one squad per site".
-  2. `mKey` is the credential that lets a console command a pod. **Siteconfig files are
-     secrets.** Sharing one with a master console = handing over control of your bay.
+  1. "Concatenating" siteconfigs = a real deserialize/merge/reserialize tool — **built:
+     [`tools/SiteConfigMerge`](../tools/SiteConfigMerge/README.md)** decodes
+     `<siteName>.siteconfig` files and merges them into `master.siteconfig`, renaming
+     squads `<siteName>-<original squad name>`. Verified against the real
+     TeslaConsole 4.11.4.1 loader. The `Squad` concept maps naturally to
+     "one squad per site".
+  2. `mKey` is the credential that lets a console command a pod — but it has **no
+     practical value outside the bay**: pods live on an air-gapped network, and
+     anyone with physical bay access has the siteconfig anyway. Handing your
+     siteconfig to the central console is simply how a site joins an event (see the
+     brainstorm's authority-handover model). Siteconfigs are exchanged
+     operator-to-operator as `<siteName>.siteconfig` and are not stored in this
+     repo — they change over time; the repo carries only the tools.
 - **vPOD** (`TeslaSuite\vPOD\`): impersonates both a pod's launcher (TCP 53290) and a
   game client (Munga TCP 1501). **This is our test double for a whole remote bay** — we
   can prototype every SiteLink flow without touching cockpit hardware.
@@ -90,8 +102,9 @@ machines on the internet.
 - **Dormant internet-era code:** MSN Zone "GUN" matchmaking (`Games_GUN.cpp`,
   `GUNGameList.h`) and GameSpy advertisement (`Games_GSpy.cpp`) — dead services, live
   code paths; a revival hook if SiteLink ever wants a fleet-wide game browser.
-- **2016 release integrated Mumble** for voice (FS507D postinstall) — cross-site voice is
-  a solved problem: one Mumble server on the shared network.
+- **Voice: backburnered.** The 2016 FS507D release integrated Mumble, but only one
+  operator ever ran it. Cross-site voice is technically easy (one server on the shared
+  network) — revisit only if event interest warrants it.
 
 ### BT411 (classic BattleTech — Tesla 4.10 reconstruction, native Win32)
 - **Console-push model over plain TCP:** the console connects to each pod's `-net <port>`
@@ -177,5 +190,5 @@ the current Windows 10 cockpit hardware. Full plan: `TeslaRel410\emulator\PLAN.m
 | 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 (event tooling, when deployed) |
 | 3306 | TCP | PQS internal | MySQL (localhost) |
-| 64738 | TCP/UDP | all → voice server | Mumble (2016 release convention) |
+| 64738 | TCP/UDP | all → voice server | Mumble (2016 release convention; voice is backburnered) |
 | 5900 | TCP | operator → pods | VNC monitoring (optional) |