Validate connector readiness rollout and retire its release flag

[devantler]

🤖 Generated by the Agentic Engineer

Part of #4; follows #48.

Problem and outcome

The connector-readiness OpenFeature release gate must remain short-lived while the first workload observation rollout is evaluated. The implementation tests are a correctness proxy; they do not establish live source or public-contract availability.

Acceptance criteria

• A Platform-owned deployment uses immutable signed release artifacts, the upgraded CRD, and exact-name namespaced Deployment get permissions.
• During the first rollout window, exercise Deployment availability loss, recovery, scaling to zero, a new generation, and access revocation; observe ConnectorReady, aggregate Ready, and registry readiness within the documented polling bound while the controller and API are available.
• Verify product inputs and provisioned-source conditions remain compatible; confirm the observer creates no workloads, reads no Secrets, and does not query data-plane or public contract URLs.
• Record public-safe acceptance evidence on Integrate existing sources and publish standard query contracts #4 and compare it with the implementation's lifecycle proxy.
• Remove CONNECTOR_READINESS_ENABLED, the connector-readiness OpenFeature gate, and its Helm release toggle in a focused PR after acceptance, retaining explicit reference and access boundaries.

The first Platform rollout defines the measurement window; this issue is not evidence of production acceptance. #46 separately owns the HTTP export workload's rollout and its own release flag. Rough size: M.

[devantler]

🤖 Generated by the Agentic Engineer

#50 is merged as c1a32d1887244c9df8525103827d1938ba58430a; the verified v1.3.0 tag points directly to that commit. Release, chart publication, application publication and the post-merge analysis workflows all succeeded. The merged tree matches the reviewed tree, and the connector lifecycle/HTTP tests passed again with the Go race detector on the merge commit.

Immutable published artifacts:

Artifact	Reference
Controller image	ghcr.io/devantler-tech/data-product-controller@sha256:3eaa1420bc285096bb26c94cc937b4aa7f6b9eebabb11f5807a21d3365c61211
Helm chart 1.3.0	ghcr.io/devantler-tech/charts/data-product-controller@sha256:dd01807702a14c48acddcd8a6e152032e6d13475659fe1b890cdaa9e91cf4097
Manifests	ghcr.io/devantler-tech/data-product-controller/manifests@sha256:074f5134bcd19fb19f25c92872b90ae4bd7eeeb0a1eb2685dfc64e963aa65a58

All three digests passed independent local Cosign verification: signature claims, transparency-log presence, trusted certificate chain, GitHub Actions OIDC issuer, and the expected workflow identity. The chart identity is the repository's publish-chart.yaml@refs/tags/v1.3.0; image/manifests use the tagged caller or the exact shared publisher pinned at 4f4e07a3ebf3e1161756a292966e36c91a65ee04.

Chart publication and image/manifest publication provide the forge evidence.

The downloaded chart's digest matched the signed artifact. Its connector CRD schema and both flag states render correctly. Post-publication rendering exposed the pre-existing image default defect now tracked in #51: without an override, the chart still uses tag 0.1.0. Supplying image.digest=sha256:3eaa1420bc285096bb26c94cc937b4aa7f6b9eebabb11f5807a21d3365c61211 was verified to render the exact v1.3.0 image and takes precedence over that stale tag. Use that immutable image pin for acceptance.

This remains release evidence, not live adoption evidence. Keep the feature disabled until the Platform-owned rollout deliberately supplies the updated CRD and exact-name Deployment GET grants, then complete this issue's lifecycle, compatibility and flag-retirement acceptance. #4 and this issue remain open.