docs(roadmap): T41a needs a VM and not a certificate, so T94 takes the half that does

[haiquang9994]

T41a asked two questions and only one of them cost money. This splits them, and corrects two
orderings that were wrong before the split made them visible.

What stays in T41a

The measurement: does a freshly built unsigned binary load on its first run under Smart App Control,
and does the elevated hosts write survive Defender's HostsFileHijack heuristic. That needs a clean
Windows VM and nothing bought — and it is the half that tests the code phase 4 just built.

What moves, and why it is not only about who has a certificate

The certificate question shrank between T41a being written and now. Its own remedy was "buy the
cheapest usable certificate and try it on the VM". T20a and T27 have since measured the runtimes: of
the four borrowed ones, only Node is signed upstream. So a certificate MixEngine buys signs
MixEngine's own binaries and does nothing for PHP, nginx or Caddy — the binaries this product exists
to start.

runtime-packaging.md had already drawn that conclusion and nothing upstream of it had been
updated:

SAC would refuse the same artifacts even if MixEngine shipped none of its own.

Signing them all would mean building them all, which is the trade "borrow before you build" refused
on maintenance cost — and which would have to be re-argued rather than assumed.

So T94 is three readings and not one: what a certificate covers, what it leaves uncovered, and
what the cheapest thing covering the rest is. It sits in phase 9 because its answer changes how the
product is distributed, while T41a's can invalidate ADR 0005 and the five phases resting on it —
which is why that one was written early and stays early.

Two orderings corrected

The population count was T41a's first question and was the wrong first question. While a remedy
is open, 30% and 60% lead to the same next move. It moves to T94 and comes last, where it
decides between remedies instead of describing a problem.

And what T41a should read on the VM is now named. updates.md records that the 2026-08-13
refusal did not persist — the same binaries ran unchanged hours later, which reads as an ISG
reputation lookup that had not answered yet. That does not soften the question, it locates it: a
user's first launch is the first-seen case, and a first run that fails followed by a second that
works is still a first run that failed, on the one occasion when nobody has a reason to try twice.
So the reading is the first run of a freshly built binary, and whether it recovers.

Files

phase-4 rewrites T41a's middle; phase-9 gains T94 after T86a and corrects T86a's "two halves" to
three; todo.md updates the index row, the debt table and the phase-4 prose. updates.md and
standards/testing.md both pointed at T41a for the population number and now point at the half that
owns it.

Markdown only — no job in ci.yml reads it, so no CI run was requested.