Withdraws this deployment's key-protection backend declaration and returns the platform to the un-declared first-run state, so a different backend can be declared after a failed or abandoned activation.

Available while at least one bootstrap tenant lacks an active key-encryption key; refused 409 once both hold one. After that point the backend may already have wrapped key material, and withdrawing the declaration that reaches it would orphan that material irrecoverably. Every uncertainty resolves to still-bound: a contradicted claim, an unverifiable one, and a boundness read that fails are all refused.

What the operation clears — all of it, not only the row this path is named after:

• deployment_info.declared_backend, the declared backend token;
• the DEPLOYMENT-scope key-backend descriptor row, holding the saved coordinates;
• the sealed deployment credential, its retained .previous and any stranded rotation .candidate;
• the bootstrap tenants' active key-encryption key rows, whose orphaned references are named in the audit trail.

Returning to a backend costs a re-seal. The credential is not kept per backend, so the envelope this withdrawal disposes is gone: declaring the same backend again requires supplying its credential again, and there is no restore point across the change.

Idempotent: a deployment holding none of those artefacts answers 204 and changes nothing.

ROOT tenant only, and it requires BOTH platform.bootstrap AND admin.platform.deployment-secret.write — the same pair PATCH /backend/credential requires. Deleting a sealed envelope is a

mutation of the sealed value, so it carries the scope that writes one; the
bootstrap scope alone declares, configures and activates, and still cannot reach
a deployment secret.