[Feature] Track KubeFleet release-process changes downstream

**Is your feature request related to a problem? Please describe.**

KubeFleet is reworking its release process upstream ([kubefleet-dev/kubefleet#693](https://github.com/kubefleet-dev/kubefleet/issues/693)) — atomic orchestrator, cosign signing, multi-arch images, multi-minor upgrade tests, `release-metadata.json` published as a Release asset, etc.

Today, AzureFleet learns about new upstream releases manually. There is no automation to detect new tags, no verification of upstream lineage, no test pipeline that runs Azure-specific overlays against the bumped upstream code, and no provenance link from MCR images back to the upstream KubeFleet artifact.

**Describe the solution you'd like**

This epic tracks AzureFleet's downstream-side work — discovery, verification, and consumption of upstream releases, plus Azure-specific compatibility surface. Subtasks will be filed as separate issues from this epic as work begins.

### Pull-side automation

- [ ] Nightly cron workflow (`.github/workflows/upstream-poll.yml`): fetch latest upstream GA tag, skip pre-releases, deduplicate against `go.mod`
- [ ] Verify upstream lineage: `cosign verify` against image digest from `release-metadata.json`. Abort + alert on signature failure
- [ ] Auto-open bump PR (`bump/kubefleet-vX.Y.Z`): bump `go.mod`, `go mod tidy`, regenerate manifests
- [ ] Post breaking-change + CRD-change list as PR comment, sourced from `release-metadata.json`

### CI overlay on bump PRs

- [ ] Consume upstream's reusable upgrade-test workflow (`uses: kubefleet-dev/kubefleet/.github/workflows/upgrade.yml@`) once it lands upstream
- [ ] Layer Azure overlay tests on bump PRs: Arc chart compat, Deployment + ManagedResource webhook tests, ManagedResource VAP, `cmd/crdinstaller` upgrade path

### Compatibility documentation

- [ ] AzureFleet `VERSIONING.md`: Azure-specific compat axes (Arc chart, Deployment + ManagedResource webhooks, `cmd/crdinstaller`) + version-map table to upstream
- [ ] Document AzureFleet support window (may differ from upstream — call out explicitly)

### MCR pipeline provenance

- [ ] Capture upstream tag + Rekor URI from `release-metadata.json` at bump time; pass through the build pipeline
- [ ] MCR build attestation references upstream Rekor entry — preserves verifiable lineage from KubeFleet tag → MCR image
- [ ] Document verification path (Microsoft signature → upstream Rekor → KubeFleet tag) in README / SECURITY.md

### Coordination with upstream

- [ ] Decide `cmd/crdinstaller/` ownership with upstream maintainers — resolve before KubeFleet ships its standalone CRD tarball
- [ ] Add `CONTRIBUTING.md` rule: core changes go upstream first; Azure-specific code uses existing extension points (`pkg/propertyprovider/azure`, `types_azure.go` pattern)

**Describe alternatives you've considered**

1. **Status quo (manual bumps)** — fragile, no upstream signature verification, doesn't scale.
2. **`repository_dispatch` from upstream** — rejected: couples a CNCF sandbox project to a specific commercial consumer; pull-based is the open-source norm and avoids credential lifecycle on the upstream side.
3. **GitHub release-publish webhook subscription** — viable alternative to cron polling. Cron preferred today for simplicity; can revisit if cadence tightens.

**Additional context**

Pairs with upstream tracking issue [kubefleet-dev/kubefleet#693](https://github.com/kubefleet-dev/kubefleet/issues/693). The full downstream desired-state flow (detect → verify → propose → human gate → MCR build) is documented in the planning doc under "Downstream — nightly poll: detect, verify, propose."