core.arch is silently ignored after init (BasePatch resolves the arch into base.yaml)

[lacraig2]

Summary

Setting core.arch in a project's config.yaml after penguin init has no
effect. The run proceeds on the architecture ArchId picked at init time, with no
warning that the requested value was ignored.

Reproduce

penguin init fw.rootfs.tar.gz --output proj
# proj/static/ArchId.yaml says e.g. mips64eb
python3 - <<'PY'
import yaml
c = yaml.safe_load(open("proj/config.yaml"))
c.setdefault("core", {})["arch"] = "armel"
yaml.safe_dump(c, open("proj/config.yaml", "w"), sort_keys=False)
PY
penguin run proj --auto
# console still shows the original architecture's machine, e.g.
#   [    0.000000] MIPS: machine is mti,malta

Cause

ArchId feeds BasePatch, which resolves the architecture into
static_patches/base.yaml at init time — kernel image, machine type and the rest
of the arch-dependent config are already materialised there. core.arch in
config.yaml is not consulted again at run time, so editing it changes nothing
that the run reads.

Why it matters

core.arch exists precisely so a human can override detection — the ArchId
docstring says so: "If the architecture can't be determined, this analysis (and
everything consuming it, notably BasePatch) fails and is skipped - init still
completes so the user can fill in core.arch by hand." That path works when
detection fails. It silently does not work when detection succeeds and is
wrong, which is the more common case (see #922) and the one a user is most
likely to try to fix by hand.

The failure is silent, which is the worst part: the run looks like it honoured the
override, and the resulting panic gets attributed to the firmware.

Options

1. Have run compare core.arch against the arch baked into base.yaml and
   fail loudly on mismatch, telling the user to re-init. Cheapest, and removes
   the silent-wrong-answer case.
2. Accept an arch override at init time (e.g. penguin init --arch), so
   BasePatch resolves against the user's value. This is what someone
   overriding detection actually wants.
3. Re-resolve the arch-dependent parts of base.yaml at run time when
   core.arch is set. Most flexible, most work, and probably not worth it.

(1) and (2) together would cover it: a clear error for the stale-project case and
a supported way to get the right project in the first place.