Make config dataclasses the single source of truth for DEFAULT_CONFIG

DEFAULT_CONFIG and build_models/build_critics/StageSpec.from_config's
inline .get(key, default) fallbacks had already drifted: two keys
(stage2_model.decoder, stage2_model.particle_type.target) resolved
differently depending on whether a config dict came from
merge_cli_overrides (fully populated, correct) or was hand-built and
partial (fell back to stale v0.2-shaped literals). Introduce frozen
dataclasses (GiantConfig and its nested blocks) in giant/config.py as
the actual single declaration of every default; DEFAULT_CONFIG is now
generated from them instead of hand-maintained, and build_models,
build_critics, and StageSpec.from_config consume the dataclasses
instead of duplicating literal fallbacks, so this class of drift can't
recur. Router/n_sec sub-blocks keep an `extra` catch-all for their
genuinely dynamic keys (composed-router axes, runtime-seeded
centers_init, legacy_owner).

Fixing the fallback surfaced the same latent bug in two existing
partial-config callers that had been silently depending on it: a
test fixture in test_train.py and scripts/warm_setup_cache.py's
minimal cfg (now merged against DEFAULT_CONFIG instead of hand-rolled,
closing the gap for good). See issues.md Issue 1.

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

scripts/warm_setup_cache.py

@@ -9,6 +9,7 @@ for the sidecar itself.
 
 from pathlib import Path
 
+from giant import config as gconfig
 from giant.constants import K_MAX
 from giant.pipeline import run_setup_stage
 
@@ -43,19 +44,25 @@ def run_warm_setup_cache(
         "type": router_type,
         "n_experts": n_experts,
     }
-    # A minimal v0.3 cfg — only the keys run_setup_stage actually reads
-    # (conditioning.{particle,material}.type, stage{1,2}_model.router). This
-    # CLI only ever configures one router (matching today's single
+    # Merged against DEFAULT_CONFIG (not a hand-rolled partial dict) so
+    # run_setup_stage always sees every key it might read (e.g.
+    # conditioning.particle.emb_dim, stage2_model.particle_type.target) at
+    # its real default, not silently missing/None — see issues.md Issue 1.
+    # This CLI only ever configures one router (matching today's single
     # --router-type flag), so it's placed on stage1_model; stage2_model's
     # stays disabled.
-    cfg = {
-        "conditioning": {
-            "particle": {"type": particle_conditioning},
-            "material": {"type": material_conditioning},
+    cfg = gconfig.merge_cli_overrides(
+        gconfig.DEFAULT_CONFIG,
+        None,
+        {
+            "conditioning": {
+                "particle": {"type": particle_conditioning},
+                "material": {"type": material_conditioning},
+            },
+            "stage1_model": {"router": router_cfg},
+            "stage2_model": {"router": {"enabled": False}, "k_max": K_MAX},
         },
-        "stage1_model": {"router": router_cfg},
-        "stage2_model": {"router": {"enabled": False}, "k_max": K_MAX},
-    }
+    )
     run_setup_stage(
         Path(data),
         val_fraction=val_fraction,