[Config] Round 6.1: "unset" gets its own spelling, and the declaration says what it means

[ch-wan]

First of five. The stack continues a series that moved configuration out of
ServerArgs and into the runtime context's namespace bags. This one fixes
something that was actually broken, and gives the fix its other half.

"Unset" gets its own spelling on two ratio fields

swa_full_tokens_ratio and mamba_full_memory_ratio carried real values as
their class defaults (0.8, 0.9), so a model family with an opinion had to ask
"is this field still equal to the class default?" to find out whether the
operator had set it. That question has two wrong answers: it says "the operator
set it" as soon as any earlier pass declares the field, and it says "the
operator did not set it" when the operator types the default value.

Both become Optional[float] = None. The record carries what the operator typed
and nothing else, and the family test becomes is None.

mamba_radix_cache_strategy keeps "auto": unlike the ratios it already has a
spelling for "unset" that an operator can type and that means exactly that --
only its comparison changes, from the class default to the token itself, which
is the fix the comment at that site already prescribed. With that, neither
family module imports ServerArgs any more.

And the declaration says what the field means when nobody answers

Making the default None leaves a hole: something has to supply the generic
value. Arg(fallback=...) supplies it from the declaration.

swa_full_tokens_ratio: A[
    Optional[float],
    Arg(help="...", resolvable=True, fallback=0.8),
    NS("schedule"),
] = None

The dataclass default stays None. A fallback is not a default: the record is
the wire format, and a child process has to keep being able to tell "unset" from
"set to the value resolution would have picked anyway".

Which surface it lives on is the whole design

Precedence becomes override -> decision -> input -> fallback, applied in
resolution_result -- which the projection, /server_info and every config bag
read through.

Deliberately not in resolving_view / resolved_view. Those are the
decision-over-input surface a pass reads while it is deciding, and two model
families branch on exactly this:

# model_overrides/inkling.py, and the same shape in deepseek_v4.py
if cfg.swa_full_tokens_ratio is None:
    overrides["swa_full_tokens_ratio"] = 0.1

A fallback answering there is not "the generic value, later" -- a __getattr__
layer is read-time, so there is no later. Every read during resolution would
already get 0.8 and the branch would never fire. Running _inkling_overrides
against both versions:

--- fallback on the effective surface only (this PR) ---
  cfg.swa_full_tokens_ratio during resolution = None
  family declared swa = 0.1   mamba = 0.1
--- fallback also on the view a pass reads ---
  cfg.swa_full_tokens_ratio during resolution = 0.8
  family declared swa = None  mamba = None      <- the key never lands

So "resolution first, then the fallback" holds -- not because a step is appended
to the pipeline, but because of which surface the value lives on. Exactly one
reader consults the effective surface during resolution: the range check on the
ratio, which wants the value the pools will be sized against. It asks
resolution_result directly -- what its comment already claimed it was doing --
and it runs after the model families.

The alternative, and why not

A pass that fills the field in when nothing claimed it needs a slot (after the
families, or it beats them), a second call site (the dummy-model short circuit
returns long before that slot), an idempotence requirement so the second call is
harmless, and the value written twice -- once as a literal, once as prose in the
help ("Unset means 0.8"). An earlier revision of this series did exactly that
and deleted it four PRs later. A declaration needs none of it, and pipeline.py
is untouched by the whole series as a result.

What may be declared this way, and what may not

Across every hook, if x is None: x = ... appears at 55 sites over 29
fields. They are not one thing:

	count	examples	declarable
unconditional constant	5	the two ratios, grammar_backend="xgrammar", mm_process_config={}, custom_weight_loader=[]	yes
unconditional, computed from another field	4	tokenizer_path=model_path, device=get_device(), served_model_name, speculative_draft_model_quantization	needs a fallback="dotted.path" form; not here
conditional decision	~20	chunked_prefill_size across seven memory tiers, max_bs across eight, max_running_requests at 48 or 256 by model family	no, and it should not be

Only a value fixed for the life of the configuration belongs in a declaration.
One that depends on the machine, on another field, or on anything impure
(random_seed = random.randint(...)) is a decision, and decisions stay in a hook
where their order is visible. This PR converts the two ratios only.

Verification

• resolve_once ends with the same effective values: the resolution result is
  identical across 24 launch shapes x 489 fields except for the two intended
  ratio changes. Separately, 16 launch shapes resolved on both sides, real model
  and dummy: 7,904 field readings, and the only difference is random_seed, a
  fresh random.randint per process.
• The CLI registers the same 507 options with the same choices and actions; only
  the two defaults move.
• test_declared_fallbacks.py, 17 cases. One pins the inverse of the dead branch
  above: what a pass sees while deciding is still None.
• The whole series was swept over all 648 registered unit-test files against its
  merge-base: 19 failures on both sides, the same 19, none of them config.

---

CI States

Latest PR Test (Base): ❌ Run #34083705463
Latest PR Test (Extra): ❌ Run #34083705284
Latest PR Test (AMD ROCm 7.2): ❌ Run #34083705383