docs root-ceremony: the provisional root has no backup, and what v1.0 changes

[avrabe]

Follows #110.

The topic prescribes paper backup in two locations, split custody over the seed, an access log and an annual read test — and never mentioned that varve's own provisional rolling key has none of them. It was generated straight into CI; its secret half exists in exactly one place, a write-only Actions secret nobody can read back.

"Provisional" reads far milder than that, so the consequences are now stated flatly: it cannot be moved (which is why a realm's contents live in their own repo while the signing step stays where the secret is), cannot be recovered, and must not be extracted — printing a secret into a workflow log would expose the root permanently, and with no rotation and no revocation the only remedy is abandoning the realm.

A key with a single write-only copy is not in custody.

Also adds a "What changes at v1.0" section — REQ-CEREMONY-001 was referenced repeatedly and never described in one place.

On keyless, recorded as open rather than settled

Verified against wsc 0.11.0 source today, not from the earlier decision:

• DD-026's stub argument has expired. The air-gapped verifier is no longer a stub — 1241 lines doing real certificate-chain, Rekor SET, ECDSA-P256, revocation and identity checks offline, and it documents the two things it deliberately skips (Rekor Merkle inclusion, because the verifier computes the wrong shard root for Rekor v2 and failing closed would reject legitimate signatures; and SCT/CT, for want of a provisioned CT key).
• DD-026's structural argument still stands, in wsc's own doc comment: "The bundle is signed with a long-lived offline key. Devices verify the signature against a pre-provisioned public key before using." Keyless relocates the long-lived secret; it does not abolish it.
• But relocation is close to the whole point. The pulseengine rolling root exists only as a write-only CI secret: no backup, no way to move it, and no rotation if it is lost #110 is the argument: today's long-lived key sits in CI, is used on every deposit, and cannot be backed up or moved. A bundle-signing key is used rarely and can plausibly be held the way this topic prescribes. The question for v1.0 is not "keys or no keys", it is which key has to be online.

Docs coverage gate green; workspace suite green.