feat: hub self-adoption — pivot management from ephemeral kind to hub EKS

## Problem

Currently the bootstrap kind cluster must remain **permanently alive** to host KRO/ACK controllers that manage `peeks-hub` and spoke clusters. This causes several issues:

- **Credential expiry**: The kind cluster uses EC2 instance role STS tokens (~1h) via a `aws-credentials` secret. After expiry, ACK controllers lose access → PIAs stuck, EksCluster stuck IN_PROGRESS, manual `task credentials:refresh` required.
- **Persistent EC2 dependency**: The kind cluster runs inside the IDE EC2. If the IDE is restarted or SSM session expires, the kind cluster is lost and the entire management plane is gone.
- **Non-idiomatic**: Using a local kind cluster as the long-running control plane for production EKS clusters is fragile.

## Proposed Solution: Hub Self-Adoption (CAPI Pivot Pattern)

Inspired by [Cluster API pivot](https://cluster-api.sigs.k8s.io/clusterctl/commands/move.html), the idea is to move the management of `peeks-hub` from the ephemeral kind cluster to the hub EKS cluster itself.

### Phases

**Phase 1 (today):** Kind bootstrap → creates peeks-hub
```
kind (ephemeral) ──KRO/ACK──→ creates peeks-hub EKS
│
▼
ArgoCD/KRO/ACK (EKS Capabilities)
```

**Phase 2 (proposed):** hub:pivot → peeks-hub self-manages
```
peeks-hub ──KRO/ACK (in-cluster)──→ adopts its own EksCluster resource
peeks-hub ──KRO/ACK──→ manages spoke clusters
kind → destroyed (no longer needed)
```

### Implementation Steps

1. **Install KRO + ACK on peeks-hub** (as EKS Capabilities — already done today)
2. **Export EksCluster manifest from kind** — serialize the current `EksCluster/peeks-hub` resource
3. **Apply on peeks-hub context** — with `adopt: true` or by setting the correct owner references so ACK adopts the existing AWS resources instead of recreating them
4. **Delete from kind** — remove the `EksCluster` resource from kind (ACK will not delete the AWS resources if adopted properly)
5. **Pivot spoke management** — move spoke `EksClusters` to peeks-hub context
6. **Destroy kind** — `kind delete cluster`

### Benefits

- ✅ No credential expiry (EKS PodIdentity, never temporary tokens)
- ✅ No kind cluster to maintain after bootstrap
- ✅ `task destroy` becomes cleaner (no kind dependency)
- ✅ Better resilience — hub EKS is the durable control plane
- ✅ Consistent with fleet model (hub manages spokes)

### Challenges

- ACK adopt-or-create semantics for existing resources
- Circular dependency during bootstrap (need kind to create hub, then pivot)
- Crossplane on hub must be re-pointed to hub context for spoke management
- `EksCluster` RGD may need `adoptionPolicy` support

### References

- CAPI Pivot: https://cluster-api.sigs.k8s.io/clusterctl/commands/move
- ACK Adopt Existing Resources: https://aws-controllers-k8s.github.io/community/docs/user-docs/adopt-resources/
- Related: credentials:refresh workaround in `cluster-providers/kind-kro-ack/Taskfile.yaml`

## Acceptance Criteria

- [ ] `task hub:pivot` moves management from kind to peeks-hub
- [ ] `kind delete cluster` succeeds after pivot without breaking peeks-hub or spokes
- [ ] No `credentials:refresh` needed after pivot
- [ ] `task install` re-run after pivot still works (idempotent)

Start with cluster-providers/kind-kro-ack/Taskfile.yaml and trace the existing credentials:refresh, install, and destroy flows. Then identify how hub:pivot would export and apply the EksCluster resource across the kind and peeks-hub contexts. Done means the stated acceptance checks pass, including deleting kind without breaking the hub or spokes and rerunning task install idempotently.

Written by the indexing model from the issue text.