Back-to-back missions: relay re-arms on rejoin (no Stop/Start needed)

Field report: after a mission timed out normally, relaunching a mission
did nothing.  The relay was single-mission -- once it fired a launch
(launches_sent==2) it never re-armed.

Fix (operator-side only; the BINARY needs nothing -- a rejoined pod is a
brand-new process at WaitingForLaunch):
- btconsole _check_launch_gate: when a previous mission finished
  (launches_sent==2) and ALL seats have RE-ACKED (every pod exited,
  re-ran join.bat, reconnected), reset the launch state and re-print
  'WAITING FOR OPERATOR LAUNCH'.  Only reachable on a pod ACK (never
  mid-mission).  Launch is CONSUMED after RunMission #2 (launch_at=None,
  launch_requested=False) so the next press is a deliberate new round.
- btoperator SessionMonitor: reset  on each new
  'WAITING FOR OPERATOR' so the LAUNCH button RE-ENABLES for mission 2
  (it stayed disabled forever before -- the other half of the bug).

Verified e2e: two full missions on ONE relay session -- mission 1 runs +
times out on the clock, pods rejoin, relay re-arms + re-announces ready,
operator LAUNCH -> mission 2's RunMission #1/#2 fire (total fires 2) ->
pods running.  BACK-TO-BACK PASS.  Friends' zip unchanged.

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

tools/btoperator.py

@@ -85,7 +85,12 @@ class SessionMonitor:
                 self.eggs = int(m.group(1))
                 changed = True
             if self.RE_RELAY_READY.search(line):
+                # WAITING FOR OPERATOR = pods are ready to launch.  Reset
+                # `launched` so the LAUNCH button re-enables -- this fires
+                # again for a NEW mission after the pods rejoin (back-to-back
+                # missions, 2026-07-18), not only the first time.
                 self.ready = True
+                self.launched = False
                 changed = True
             m = self.RE_RELAY_REG.search(line)
             if m: