harden: /CETCOMPAT (backward-edge CFI) + machine-enforced mitigation coverage

[bgonz808]

Two additions from the nightly-feature research, both made enforced rather than merely set — a mitigation we asked for is not a mitigation we have.

/CETCOMPAT — the missing half of control-flow integrity

control-flow-guard=checks has protected indirect calls since the beginning. Nothing protected returns. /CETCOMPAT marks the image compatible with the CPU's hardware shadow stack, which keeps a protected copy of return addresses and faults on divergence — the direct answer to ROP, which CFG does not address.

• Stable — plain linker flag, no nightly needed
• Measured cost: 0 bytes
• Compatibility: it's a mark, not a requirement. MSVC docs describe it as telling the linker to "mark the binary as CET Shadow Stack-compatible". Windows enables shadow stacks only where CPU and OS support them and the image opts in; on hardware without CET there is nothing to enable. Every x86_64 CPU still runs the binary — the ones with CET run it with more protection. x64-only per the same docs, which is our only target.

-Z deny-partial-mitigations=stack-protector,control-flow-guard

Turns a comment into an invariant. The config asserted "build-std rebuilds std with it too, so protection is whole-binary" — true, and unverified. Now the build fails if any crate in the graph, std included, is compiled without those mitigations.

Partial application is the dangerous case precisely because the binary carries the flag and the reassurance while leaving gaps. Upstream intends this as the default (rust-lang/rust#157941) — adopting now means passing by construction rather than by luck.

Enforcement, not just configuration

CET does not live in the optional header's DllCharacteristics like ASLR/DEP/CFG — it travels in a debug-directory entry of type 20 (IMAGE_DEBUG_TYPE_EX_DLLCHARACTERISTICS), so it needed its own reader. CET_COMPAT is now measured structurally and ratcheted with the rest: lose it and the gate fires.

Recorded under its own name rather than folded into CONTROL_FLOW_GUARD because the two are independently settable and defend opposite edges — collapsing them would let one vanish while the manifest still looked complete.

Verified both directions (the #303 lesson): decoder reports CET_COMPAT absent on every binary built so far (none used the flag), and unit tests pin the positive case — including that an unrelated extended bit must not read as CET. 84 tests pass.

Expected on the next build

The caps gate will fire: hardening CHANGED: binary has CET_COMPAT, manifest does not declare it. That's the ratchet working. Manifests are deliberately not pre-updated — they should describe measured reality, not assert a posture ahead of measuring it.

On OS-scoping (asked, and already correct)

No change needed: these flags live under [target.x86_64-pc-windows-msvc], so they're applied per-target by construction. A future Linux target would carry its own section and inherit none of this.