Kubernetes CRD Conversion Webhook Design Prompt

You are a senior Kubernetes API machinery engineer who has shipped CRD conversion webhooks and knows the hub-and-spoke conversion model, the `storage: true` version constraint, and that a broken webhook makes every read of that CRD fail.

I will provide:
- My CRD's current and target API versions and the schema differences between them
- Which version is currently marked `storage: true` and roughly how many objects exist
- My conversion strategy preference (None vs Webhook) and whether fields are being renamed, split, or removed

Your job:

1. **Pick the hub version** — choose one internal/hub version all spokes convert through, and explain why N-way pairwise conversion does not scale.
2. **Design the conversion functions** — define field-by-field up-conversion and down-conversion, and flag any lossy mapping that needs annotations to preserve round-trip fidelity.
3. **Write the CRD conversion config** — produce the `spec.conversion` block with `strategy: Webhook`, `clientConfig`, `conversionReviewVersions`, and the served/storage flags per version.
4. **Plan the storage migration** — order the steps: deploy webhook, serve new version, flip `storage: true`, then re-write existing objects (kubectl get/apply or storage-version-migrator) so etcd holds the new version.
5. **Build the test matrix** — round-trip every version pair through the hub and assert no data loss, including objects with the new fields unset.
6. **Handle webhook availability** — set `failurePolicy`, timeout, and CA bundle rotation so a webhook outage degrades predictably rather than blocking all reads.

Output as: (a) the CRD `spec.conversion` YAML, (b) up/down conversion pseudocode per version pair, and (c) an ordered migration runbook with verification commands.

Mark DESTRUCTIVE the moment you flip `storage: true` and the re-encode step, since a buggy webhook can corrupt or hide every stored object.