Provision editable Cloudflare WordPress sites from static artifacts

## Goal

Expose a remote API that accepts a bounded static website artifact, provisions an isolated Cloudflare WordPress site, materializes it as editable Gutenberg content through Static Site Importer, persists canonical state through MDI/D1/R2, publishes immutable routes, and returns a durable operation receipt plus site URL.

## Architecture

- one shared Worker with hostname-derived site identity
- shared D1 registry/coordinator with strict `site_id` isolation
- shared R2 bucket with `sites/{siteId}/...` namespaces
- Static Site Importer owns artifact validation, Blocks Engine compilation, WordPress site-plan materialization, and import reports
- WP Codebox owns authentication, bounded artifact transport, coordinator leases, canonical persistence, publication, and lifecycle receipts

## Tracked slices

- [x] #1976
- [x] #1975
- [x] #1972
- [x] #1973
- [x] #1971
- [x] #1974

## Dependency order

1. Finish lossless D1 activation (#1976).
2. Prove SSI import in the existing single-site transaction (#1975).
3. Generalize all state and caches by site identity (#1972).
4. Add durable resumable lifecycle records (#1973).
5. Expose the authenticated provisioning API (#1971).
6. Prove producer interoperability and acceptance (#1974).

## Acceptance

A remote `POST /v1/sites` with a digest-verified WP Build/SSI website artifact returns `202`, progresses through a durable operation, and produces an isolated hostname whose pages are editable Gutenberg blocks, survive cold restart, publish through R2, and support subsequent canonical `N+1` edits. Repeated idempotency keys create nothing twice; concurrent sites cannot read or mutate one another. Generated-site acceptance requires zero fallback blocks and exact visual parity.

## Existing foundations

- #1863 canonical MDI/R2/Worker state
- #1968 exact coordinator-state adoption
- Static Site Importer artifact and `blocks-engine/wordpress-site-plan/v2` contracts
- Studio draft Automattic/studio#3952

This parent issue tracks the complete program; implementation remains split into independently reviewable child issues.

Start with the child issues in the stated dependency order, beginning with #1976 and #1975, and read the existing MDI/R2/Worker state and Static Site Importer contracts. The work is complete when the acceptance scenario succeeds: an authenticated idempotent request produces an isolated editable site, durable operation receipt, immutable publication, and zero fallback blocks.

Written by the indexing model from the issue text.