allocate AP kernel/IST stacks at bring-up, not statically

Hoist max_cpus into danos (root.zig), raise it to 128, and stop reserving a static [max_cpus][16 KiB] IST array. Only the BSP's IST stack is static (needed before the allocator); each AP's is heap-allocated when it comes online. Shrinks the kernel from ~1.1 MB to ~139 KiB in ReleaseSmall.

docs/smp.md

@@ -203,6 +203,13 @@ next lands.
   [scheduling.md](scheduling.md#affinity-pinning-a-task-to-a-core)). The `affinity`
   test confirms a pinned task never migrates. This is the mechanism the fault-on-AP
   test rides on, and the *explicit-affinity* real-time-predictable model.
+- **Right-sized footprint** — the per-CPU ceiling (`danos.max_cpus`, one constant
+  shared by discovery, the scheduler, and the per-core GDT/TSS) is generous (128), but
+  the *large* per-core resources — the kernel and IST (double-fault) stacks — are
+  **heap-allocated at bring-up**, only for cores that actually come online. Only the
+  BSP's IST stack is static, because it must exist before the frame allocator does.
+  This kept the kernel image small (a static `[128][16 KiB]` IST array would have been
+  2 MiB of `.bss`); it's a few tens of KiB instead.
 - **`single_threaded` off** — the kernel was built `single_threaded = true`, which
   compiles `std.atomic` down to plain non-atomic ops. Harmless on one core, but it
   quietly breaks the big kernel lock across cores; it's now `false`.