Add first-class maildesk-cf provisioning surface

[rogu3bear]

Context

The public maildesk-cf template now documents a required cfctl control-plane surface for production provisioning and verification.

Reference docs in rogu3bear/maildesk-cf:

• docs/operations/cfctl-contract.md
• ops/cfctl/maildesk-cf.surface.md
• docs/roadmap.md

Needed Change

Add a first-class cfctl maildesk-cf surface that can plan, apply, verify, and snapshot the resources required by the template.

Desired command shape:

cfctl maildesk-cf init --domain example.com
cfctl maildesk-cf diff --domain example.com
cfctl maildesk-cf provision --plan
cfctl maildesk-cf provision --ack-plan <operation-id>
cfctl maildesk-cf verify --domain example.com
cfctl maildesk-cf snapshot

Required Resource Coverage

• Email Routing rules for configured aliases
• Email Worker deployment and bindings
• API/UI Worker deployment and bindings
• D1 database and migrations
• R2 bucket for raw MIME and attachments
• Queue for async mail jobs
• Worker secrets and identity policy config
• DNS and sender authentication records

Acceptance Criteria

• cfctl maildesk-cf provision --plan emits an operation id and does not mutate state.
• cfctl maildesk-cf provision --ack-plan <operation-id> applies only the reviewed plan.
• cfctl maildesk-cf verify --domain example.com reads live Cloudflare state and reports drift by resource class.
• Receipts never include secret values.
• The implementation follows existing cfctl classify/guide/plan/apply conventions.

Non-Goals

• No dashboard-only happy path.
• No broad live email smoke tests by default.
• No maildesk policy logic inside cfctl beyond validating/provisioning account state.

[rogu3bear]

Update from maildesk-cf:

A concrete desired-state fixture now exists at:

• rogu3bear/maildesk-cf:config/desired-state.example.json

The private instance also has an ignored local equivalent generated from real policy. The cfctl surface should target this shape first, even if the exact serialization evolves later.

Current fixture sections:

• project
• domains with role_aliases and personal_aliases
• workers.mail_api / workers.mail_router
• storage for D1/R2/Queue
• sender
• verification

[rogu3bear]

Provisioning receipt from the first private maildesk-cf instance:\n\n- D1 production: star-maildesk-cf-db / 1e57a884-c3f4-4fab-b966-507514514da8\n- D1 preview: star-maildesk-cf-preview-db / 9c751613-ca36-4c1e-a696-ddfc8fcd6e2b\n- R2 production: star-maildesk-cf-raw-mail\n- R2 preview: star-maildesk-cf-raw-mail-preview\n- Queue: star-maildesk-cf-jobs\n- API Worker deployed: star-maildesk-cf, handlers fetch + queue\n- Email Worker deployed: star-maildesk-cf-router, handler email\n\nThe first-class maildesk surface should cover desired-state provision, migration apply, Worker deploy, binding verification, and then hand off Email Routing worker-rule setup to the dedicated Email Routing surface.

[rogu3bear]

Template alignment update: maildesk-cf commit 229b04f adds the production rollout, deliverability, and outbound identity runbooks. The future cfctl maildesk-cf provision/verify surface should treat those as the current public contract:

• docs/operations/production-rollout.md defines template-ready / instance-ready / edge-ready / mail-ready.
• docs/operations/deliverability.md defines DNS/authentication and low-send verification strategy.
• docs/architecture/outbound-identity.md keeps forwarded inbound mail separate from authorized domain-consistent replies.

A dedicated outbound sender verification issue is now open at #17 so this provisioning issue can stay focused on account resource lifecycle.

[rogu3bear]

Template update from maildesk-cf commit 29a28f4:

The first-class provisioner needs to treat outbound config as part of desired state, but not force every instance into the same provider. The public default is MAILDESK_OUTBOUND_MODE=disabled; Cloudflare Email Service is opt-in via an EMAIL send_email binding, while Resend is opt-in via a Worker secret.

Provision/verify should therefore model:

• API token secret present without exposing value;
• active outbound mode;
• verified sender-domain allowlist;
• provider-specific binding/secret readiness;
• audit-event path for authorized/attempted/delivered/failed replies.

That lets maildesk-cf stay Cloudflare-edge-native while still making the sender-provider adapter explicit instead of pretending inbound forwarding alone solves replies.

[rogu3bear]

proceed with full rectification plan @codex