NET-NOTES: console between-missions behavior characterized + host bridge plan

Three-mission live session on net_loop.conf: the pod side is fully
retail-faithful (netnub auto-relaunches on mission end AND console
disconnect, ~60s cycle). Console 4.10's between-missions dead-end is
app-level: its TCP receives FIN+RST from the fresh netnub yet the app
never re-queries; only an app relaunch (endpoints rebuilt from the INI)
recovers it. Selecting a printer in the Chooser makes the app launch
much faster (Printing Manager stalls without one) but does not change
the dead-end. Documented the working operator rhythm and the plan for
bridging the host-side .NET console onto the pod LAN (bridge adapter
IP 200.0.0.1/24, possible Npcap SendToRx for pod->host hairpin).

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

emulator/NET-NOTES.md

@@ -465,6 +465,52 @@ blamed before the real bug fell out. Findings, in the order they mattered:
   "resident" is fine) then `netnub -p -f btl4opt > nn.log`; TSRs and SET
   env persist from the autoexec.
 
+## Console 4.10 between-missions behavior — characterized (2026-07-09 session 2)
+
+Live A/B runs with the wire watcher (net_loop.conf pod, three missions):
+
+- **net_loop.conf VERIFIED: the pod is fully retail-faithful.** netnub
+  auto-relaunches after mission end AND after a console disconnect (both
+  observed); full cycle back to ready ~60s including the ~30s SBK
+  re-upload. Four unattended relaunches in one evening, zero touch.
+- **Console 4.10 endpoint dead-end — precisely characterized:** after a
+  mission ends, the console's TCP retries its old session, the fresh
+  netnub answers FIN then RST (so the app's stack KNOWS the session died
+  and a live pod is at ready) -- and the app never issues another query.
+  Clicking around the UI (new mission, network toggles) does NOT re-arm
+  it; only relaunching the app does (endpoints rebuild from the INI /
+  stationery at launch). Stationary.ini = the master stationery: full
+  26-cockpit roster with per-endpoint params (openTimeout=10,
+  queryTimeout=60, loadQueryInterval=1, inProgressQueryInterval=10).
+- **PRINTER: select one.** With no Chooser selection the app stalls on
+  Printing Manager calls (much slower launch; the old 'nilP' throw at
+  BTFAConsoleDoc.cp:117 is doc-init printing). A serial printer spooled
+  to file makes the app launch much faster. It does NOT fix the
+  mission-end dead-end (no print job is even attempted at mission end --
+  spool stays empty).
+- **Operational rhythm that works:** fly mission -> pod recycles itself
+  -> relaunch the Console app (fast with a printer selected) -> select
+  pod -> ready. Under two minutes of operator time per turnaround.
+  Deep fix would be PPC reverse-engineering of the endpoint state
+  machine; deferred -- the modernized .NET TeslaConsole is the long-term
+  driver.
+- Cosmetic: VDB head windows (pentapus MFDs/radar) go choppy while
+  DOSBox is unfocused and smooth when focused; total CPU was 14% so it
+  is not starvation -- DWM background-window throttling suspected.
+  Backlog.
+
+## Modern console on the HOST — bridging plan (2026-07-09, in progress)
+
+To let a Windows-host app (TeslaSuite .NET console) talk to the pod:
+give the **Network Bridge adapter** a static host IP `200.0.0.1/24`
+(no gateway; only 200.0.0.x routing changes). Host->pod already proven
+(host-stack frames appear in pod-side pcap). Pod->host may need Npcap's
+**SendToRx** per-adapter option (pcap-injected frames are normally not
+indicated up to the host stack on the same adapter -- the classic
+DOSBox-pcap guest<->host limitation); verify with a TCP connect to
+200.0.0.113:1501 and add the option only if needed. Note: a host
+connect/disconnect churns netnub (exit + ~60s relaunch) -- expected.
+
 ## Open questions / notes
 - Exact TCP listen port(s) — not in the source grep; get from NETNUB.EXE
   or a capture at milestone 3.