chore: post-release tail for 2026.8.17.1 — pin, report, and two things the self-review found - #449

Not the local build and not this machine: `xlings install mcpp@2026.8.17.1`
from the index, into a SubOS created for it, every command through
`--sandbox`. Including the one that matters most — a Windows zip packed from
inside that Linux sandbox, verified by Python's own zipfile reader.

Also records that the local-`gtc` gitcode fill was not needed this time: the
mirror leg passed on its own and was re-checked with a real GET.

`mcpp new` + `mcpp add compat.gtest@1.15.2` does not build: the scaffolded
test carries its own main() and the dependency links gtest_main.o into every
test target. Found while verifying the ecosystem, and reproduced on the
PREVIOUS release (2026.8.16.3) in the same sandbox — so it is recorded as
pre-existing, not as something this round did.

The unit tests pin the hash function — two SDK versions produce two hashes.
What they cannot see is whether the value ever gets there on a real Windows
build, and a green Windows CI does not distinguish "the identity is filled
in" from "the code path ran and produced nothing": an empty string flows
through every one of those jobs without a complaint.

So this reads resolution.json and asserts the VALUE — `runtime_id` starts
with `ucrt@`, the contract hash is non-empty (an identity that participates
in nothing is decoration), and it was NOT projected into `libc`, which names
a private libc PAYLOAD that has no ucrt equivalent.

It pins `msvc@system` explicitly. Windows' default toolchain is clang
targeting the MSVC ABI, where clang finds its own SDK and mcpp honestly has
nothing to declare — a test that took the default would assert an empty
identity and pass for the wrong reason.

…ointer

The report described the unit tests and e2e 240 but not the assertion added
after it was written — the one that says the ucrt identity reaches a real
Windows build rather than merely being computable. A report that omits the
test which closes an acceptance criterion is a report that overstates the
other evidence.

The design doc now points forward to it, so a reader who starts at the plan
finds what actually happened.

`identify()` is documented as never throwing and, for one input, terminated
the process. `std::string_view::substr` throws `std::out_of_range` when
`pos > size()`, and the position came straight out of the file:

    if (b.substr(*lfanew, 4) == "PE\0\0")

A file that starts with "MZ" and has garbage at 0x3C is ordinary malformed
input — a truncated download, a DOS stub, a text file named `.exe` — and
`mcpp pack` calls this on every artifact it packages. Measured rather than
argued: `std::string_view{256 bytes}.substr(0xFFFFFFFF, 4)` throws
`string_view::substr` under libc++.

Every other read in the module goes through a bounds-checked accessor; these
two comparisons were the exceptions, which is exactly how a module whose
stated contract is "total over nonsense" stopped being one. `has_at()` now
does the same job with the same check as the rest.

Found by re-reading the file after it was already merged and green — the
existing truncation test never produced an `e_lfanew` PAST the end, only one
exactly AT it, where `substr` is well-defined and returns empty.

The fourth is the one the report would most have been improved by hiding: a
crash in code written this round, found by re-reading it AFTER it was merged
and green. Recorded with what the existing test missed and why.

It says what it produces, and since #448 that is a .zip for a Windows target.
`--format tar` selects "an archive rather than a plain directory"; WHICH
archive follows the artifact, because a .tar.gz full of DLLs is a package most
Windows users cannot open without installing something first.

Found by smoke-testing the RELEASED binary — the behaviour shipped and its
help did not follow.

Checking the four published archives against the file whose name promises to
cover them: only `linux-x86_64` is in it — the aarch64, macOS and Windows
archives are absent, and have been for at least v2026.8.16.3 and v2026.8.15.1
too, so this is not something this round did.

The mechanism is structural rather than flaky: `build-release` (linux
x86_64) runs first and writes the file; the other three platforms upload
their own `.sha256` sidecars and nothing appends. Verification IS possible —
the sidecars are there — but not through the file that says SHA256SUMS.

Recorded as outstanding, not fixed: it is the release pipeline, not one of
the three axes, and this PR is already the post-release tail.