fix(run): mcpp build then mcpp run exec'd a bare-metal ELF on the host

[Sunrisepeak]

Shipped in 2026.8.19.2 and found by running the released binary through the
flow a new user takes:

$ mcpp new blinky --template riscv-virt-rt && cd blinky
$ mcpp run                    # ok — boots in qemu
$ mcpp build && mcpp run      # Running `target/riscv64-none-elf/…/bin/blinky`
                              # no emulator, no output, exit=1

try_fast_run exec's the cached artifact directly, and matched cache entries
whose targetTriple is "" on the reasoning — written in its own header — that
"mcpp run never takes a --target flag". The caller does guard the flag, but a
project can name its target in the MANIFEST instead, and that spelling never
reaches the cache key: a cross build's entry is written as "" and read back as
if it were a host build.

The fix states the function's actual precondition: it exec's the artifact, so
it is valid only when the artifact is for this machine. A declared default
target turns the fast path off and the full prepare — which is what resolves
the runner — takes over.

⚠️ The first version of the regression test was a false green: added to an
existing project in e2e/131 it passed with the fix disabled. Probing all 16
bail-outs showed the fast path was never reached there, because mcpp.toml was
newer than build.ninja — a rebuild does not rewrite build.ninja when its
content is unchanged, so in a directory whose manifest was edited in place the
fast path is already off. The test now builds a fresh project, and was checked
red-then-green against the fix.

Released as 2026.8.19.3.