tpm-enrol: move NV cert index off OEM-occupied 0x01800001 → 0x01800100

The Dell 820 kept "finding a cert" and bypassing enrolment despite repeated BIOS
TPM clears. tpm2_nvreadpublic revealed 0x01800001 on that hardware is a FIRMWARE
platform index (platformcreate|policydelete|writelocked, 70 bytes — not our
cert; siblings at 0x01800003/4 + 0x01810000). platformcreate survives TPM2_Clear
and policydelete needs the platform's secret policy, so it's permanent and
unusable by us — the blind check false-positived on it, and enrolment could
never write there anyway. Same class of bug as the EK-handle collision.

Move the NV cert index default 0x01800001 -> 0x01800100 (free on the 820, owner
range, overridable via rd.dot1x.nvindex): cmdline (extract-artifacts.sh),
fleet-enrol -nvindex, the dracut hooks, bench scripts, CLAUDE.md invariant #1,
and design/SSP docs. The signing-key handle (0x81000100) is unchanged.

Harden WriteNVCert: refuse a platformcreate index with a clear "pick a free
owner index via rd.dot1x.nvindex" error instead of a confusing undefine
failure. Regression simtest/TestWriteNVCertRefusesPlatformIndex; NV roundtrip +
ReadNVCert tests moved to 0x01800100. All go tests + packer validate pass.

docs/design-v2-errata.md

@@ -85,7 +85,7 @@ approval** — on an empty TPM the host generates a key *in* the TPM
 (`0x81000100`), submits a CSR to an enrolment **broker** (reachable via the same
 pre-auth permit-set, e.g. an `/enrol/` location on the serving nginx → broker →
 step-ca signer), and shows a fingerprint on the Plymouth splash; an admin
-cross-checks it and approves; the signed cert is written to NV `0x01800001` and
+cross-checks it and approves; the signed cert is written to NV `0x01800100` and
 authentication proceeds. Enrol triggers on **empty-NV only** (expired cert →
 automatic renew; auth-failure-with-cert → alert, not re-enrol). The fingerprint
 authorises *which device*; **TPM attestation** (step-ca ACME `device-attest-01`)