api: plan v1alpha2 conversion + retirement of deprecated spec.satellites.constellation

[thc1006]

Follow-up to the constellation deprecation (PR #213). The field SatelliteEphemeris.spec.satellites.constellation is now marked // Deprecated and kept in v1alpha1, but actually removing it is a versioned API migration, not a version rename — this issue tracks doing it safely.

Why a rename is not enough

The CRD currently serves a single version:

versions:
- name: v1alpha1
  served: true
  storage: true

Per the Kubernetes deprecation policy and CRD versioning, while both are served, v1alpha1 ↔ v1alpha2 must round-trip losslessly, and a stored version can only be retired after stored objects are migrated and status.storedVersions is cleaned up.

Plan (to decide/execute)

• v1alpha2 schema — drops constellation (and any other cleanups).
• Conversion strategy — webhook or (if expressible) none; preserve the constellation value on down-conversion (e.g. via an annotation) so v1alpha1 → v1alpha2 → v1alpha1 does not lose data.
• Storage migration — set v1alpha2 as storage: true, rewrite existing objects, then remove v1alpha1 from status.storedVersions.
• Serve/unserve timeline — how long v1alpha1 stays served: true before removal (alpha may be short, but still needs release notes + CR migration).
• Rollback behavior if conversion is reverted.
• Release notes / CHANGELOG for the eventual removal.

Nice-to-have (deferred from PR #213, non-blocking)

• Active deprecation signal: emit a one-time DeprecatedFieldInUse Warning event (generation-gated, NOT every reconcile) when spec.satellites.constellation is non-empty, so users applying old manifests are told, not only those who run kubectl explain.

Refs: #213 (deprecation), the deprecation-policy discussion around #209.