Disable scale-to-zero on Fly backend to fix mid-request autostop kills

Fly's "excess capacity" autostop was killing the backend machine while a
structured-dialogue reply was still generating (a request mostly waiting
on the LLM API looks idle to its scorer), causing real dropped replies on
the paid tier. kill_timeout=60 reduced but didn't eliminate the race;
min_machines_running=1 removes it entirely by never letting a machine
become autostop-eligible while serving traffic.

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

fly.toml

@@ -24,16 +24,14 @@ kill_timeout = 60
 [http_service]
   internal_port = 7860
   force_https = true
-  # Scale-to-zero: cost-conscious default, ~$0.50-1/month idle instead of
-  # ~$11/month always-on. Fly's proxy auto-starts a stopped machine on the
-  # first incoming request (cold start ~90s-2min, due to torch/transformers/
-  # faiss imports). The hourly proactive-messaging trigger (a separate Fly
-  # scheduled machine, see project memory) relies on this same auto-start.
-  # Set min_machines_running = 1 instead (and drop the two auto_* lines) if you'd
-  # rather pay for an always-on machine and remove the wake-latency entirely.
-  auto_stop_machines = "stop"
-  auto_start_machines = true
-  min_machines_running = 0
+  # Always-on (~$11/month): switched off scale-to-zero on 2026-09-29 after a
+  # real correctness bug, not just cold-start latency — Fly's "excess
+  # capacity" autostop was killing machines mid-request during longer
+  # structured-dialogue turns (the paid tier's core feature), since a request
+  # mostly waiting on the LLM API looks idle to Fly's scorer. kill_timeout=60
+  # (above) reduced but did not eliminate this; the only full fix is to never
+  # let a machine become autostop-eligible while serving traffic.
+  min_machines_running = 1
 
 # torch + transformers + sentence-transformers + faiss-cpu are all real weight —
 # a 512MB shared machine WILL OOM loading the embedding model. Start here; bump