- Create ARCHITECTURE.md with worker node sizing, simulation pod scaling,
  pod topology, resource budget, and runtime considerations
- Recommend hybrid approach: 1×20 GB on naina, 1×7 GB on ida
- Recommend Strategy C (KEDA with queue depth + resource guardrails),
  include Strategy A as alternative
- Add topology diagram, resource budget math, and Godot/Unreal comparison
- Reference ARCHITECTURE.md from README.md and PLAN.md

Refs: #6

@@ -0,0 +16,4 @@
+|--------|-------------|----------------|------|------|
+| Many small workers | 2–4 GB VMs, one per application | ~300–400 MB × N nodes | Strong isolation, independent upgrades, fault containment | High cumulative overhead, fragmented resources, more nodes to manage |
+| Few large workers | 12–20 GB VMs, multi-tenant | ~300–400 MB × 2 | Low overhead, efficient packing, simpler operations | Blast radius larger, resource contention between workloads |
+| **Hybrid (recommended)** | 1×20 GB on naina, 1×7 GB on ida | ~700 MB total | Balances isolation and efficiency; simulation workloads get a dedicated node | Slightly more complex topology; ida worker is single-purpose |

@@ -0,0 +85,4 @@
+- Requires RabbitMQ HTTP management endpoint exposure
+- More moving parts than fixed-count approach
+
+### Fixed Pod Count with Self-Limiting Simulations (Alternative)