larql run --engine is silently ignored for local models

[chrishayuk]

larql run --engine <spec> is silently ignored for local models.

Reproduction

$ larql run ~/larql-vindex/qwen3-0.6b-q4k.vindex "hi" -n 2 --engine not-an-engine
<think>

A deliberately invalid engine name is accepted and generation proceeds on the
default path. The same holds for valid-but-unused specs:

$ larql run <vindex> "The capital of France is" -n 4 --engine apollo:layer=1,coef=8.0,top_k=4
Paris.

apollo with no store attached must fail with RetrievalMiss, so an
ApolloEngine was never constructed.

Where

EngineKind::from_name is only consulted inside the remote-MoE branch of
commands/primary/run_cmd.rs (the --moe-shards gate, which rejects engines
that cannot hook remote experts). The local-model path never reads
engine_spec, so the flag has no effect and no error.

larql bench --engine is unaffected — it honours the spec, which is verifiable
from the distinct per-engine timings and labels it prints.

Why it matters beyond the flag

The same class as the strict-refusal work just merged: an interface that
accepts an instruction, ignores it, and returns an apparently valid result.
Anyone A/B-ing engines through larql run would compare the default path
against itself and conclude the engines are identical.

Suggested fix

Parse --engine unconditionally so an unknown spec is a hard error, and thread
the resolved EngineKind into the local path — or, if the local path genuinely
cannot honour it yet, reject the flag explicitly with that reason rather than
dropping it.

Found while running the engine sweep for PR #197's follow-on; pre-existing and
unrelated to those changes.

[chrishayuk]

Fixed in 879ea5f1 on worktree-vindex2.

Root cause was one line earlier than the issue guessed: walk_cmd.rs short-circuits into run_q4k_generate_cpu for a Q4K vindex on CPU with -n > 1, returning before generate_stream, which is the only code that reads the spec.

That path is not token-cached and so has no KV engine to select — it genuinely cannot honour the flag. Per the issue's second option it now refuses with the reason and a way forward (--metal, or larql bench --engine) rather than dropping it. An unparseable spec is a hard error listing the supported names, instead of a warning followed by silently running standard.

Validation lives at walk_cmd::run — the single entry — because the fan-out below it has several forward paths and only some read the spec.

Six regression tests over the two extracted pure helpers, including that every name supported_names() advertises actually validates, and that the pre-rename unlimited* aliases still do.