feat(PL-6131): make Project CR operator compatible with apimachinery meta

[davidmdm]

Note

Medium Risk
Changes the Project API shape and JSON/YAML metadata serialization; any external consumers or schemas expecting flat name/labels/annotations fields need to stay compatible with embedded metadata.

Overview
Project metadata now embeds metav1.ObjectMeta (same pattern as Environment / Release), replacing hand-rolled name, labels, and annotations fields so the Project CR matches Kubernetes apimachinery expectations for operator/controller tooling.

Call sites that constructed ProjectMetadata literals were updated to set ObjectMeta: metav1.ObjectMeta{Name: ...} instead of a top-level Name field; GetName() still reads project.ProjectMetadata.Name via the embedded meta.

^{Reviewed by Cursor Bugbot for commit fcff83e. Bugbot is set up for automated code reviews on this repo. Configure here.}

[cursor]

Cursor Bugbot has reviewed your changes using default effort and found 2 potential issues.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit 6cf8cdd. Configure here.}

[cursor]

Nested metadata in Project JSON

High Severity

The embedded metav1.ObjectMeta on ProjectMetadata is tagged json:"metadata", while EnvironmentMetadata and ReleaseMetadata only use yaml:",inline" on ObjectMeta. Project JSON therefore nests apimachinery fields under metadata.metadata instead of metadata.name / labels / annotations beside relativePath, which breaks the standard Kubernetes metadata shape this change is meant to support.

 

^{Reviewed by Cursor Bugbot for commit 6cf8cdd. Configure here.}