RavenDB-26535 Kubernetes Operator: Release Process

[poissoncorp]

This PR brings up the operator's CD. Clicking "Prepare Release" in the Actions tab + merging the auto-generated PR is enough to ship a multi-arch image, GitHub Release, and OLM bundle. The flow is complex and error-prone (mostly because of the OLM stuff - every new field needs tags, etc.), so there are plenty of opportunities for manual mistakes - that's why I've decided to go for a standardized process supplied by CD automation.

Three-phase release pipeline:

• pre-release-report skill - executed by user AI agent, makes sure CSV and samples for OLDM are right, outputs pre-release report
• prepare-release.yml - bumps versions, regenerates OLM bundle, updates Helm, opens PR
• release.yml - builds, tests, and publishes Docker images, and drafts a release tag with autogenerated release notes

OLM bundle is generated now:

• 36 +operator-sdk:csv:customresourcedefinitions: markers across api/v1/*.go drive the CSV's specDescriptors and statusDescriptors. Only new fields require manual marker work - handled by skill.
• Operator-level metadata (description, icon, keywords, links, maintainers, minKubeVersion) lives in config/manifests/bases/...csv.yaml - operator-sdk preserves it across regeneration.
• Two post-bundle seds: containerImage annotation injection (operator-sdk doesn't emit it; OperatorHub uses it for catalog display) and nodes[0].field → nodes[].field (OLM convention for "applies to all array elements").
• bundle-relocate make target moves operator-sdk's flat output into the repo's nested per-version layout.
• We lose descriptions, not sure if it's a big deal (cc @TheGoldenPlatypus) - let me know if they're useful and if we should keep them

CI gates and drift detection:

• lint-workflows.yml - actionlint on every PR touching .github/workflows/ - nice to have
• release-dryrun.yml - biweekly runs prepare + release with dry_run=true. Opens a ci-broken issue on failure so we know if the pipeline rotted before a real release needs it - another nice to have assuring my pipeline is healthy, so im able to fix it before the actual release :)
• make verify-samples - verifies config/samples/* against api/v1 types as the first step of prepare-release. Catches sample bugs when CRD fields are renamed. Lives in test/samples/ in its own package, so it runs without envtest.

Bundle prerequisites that were broken on main:

• config/samples/kustomization.yaml referenced a non-existent file (leftover from the v1 migration). Fixed.
• bundle-build had a broken docker context.
• The committed 1.0.0 CSV got regenerated from markers + base; now matches what make bundle produces and ships channels: stable (was alpha).

So, the release process is:

1. Run pre-release-report skill.
2. Open, review, and merge PR with commits from skill run.
3. Trigger prepare-release job.
4. Review the auto-generated PR.
5. Merge. If the label is still attached, release.yml auto-fires. It
6. Open OperatorHub PR, copy bundle/ravendb-operator/<version>/ → fork's operators/ravendb-operator/<version>/. Copy bundle/ravendb-operator/ci.yaml if changed.
7. Draft GH announcement request. (template WIP)