[AsadKhanAb17]

Add the admission and reconciliation foundation for project-scoped Kubernetes manifests (refs #1039). This PR does not expose a manifest upload UI, HTTP route, Helm support or deployment-pipeline integration.

The allowlist supports ConfigMaps, Secrets, ClusterIP Services, Deployments, Jobs and CronJobs inside the project's namespace. Admission rejects reserved ownership labels/annotations/selectors, owner references and finalizers at both outer objects and generated pod/job templates. It also retains the existing restrictions on host access, privileged containers, non-default service accounts, persistent claims and externally exposed Services. Project deletion recognizes the additional owned resource kinds. Manifest Deployments stay out of the native release/orphan inventory, so arbitrary manifest names cannot be mistaken for native release references or block namespace cleanup. Inventory still verifies project and runtime ownership before excluding them; namespace cleanup retains its full ownership and persistent-storage checks.

Reconciliation reads ownership first, then asks the real API server to dry-run the complete requested change before committing any writes. Existing Services retain assigned IP defaults. Jobs are explicitly create-only: a changed definition requires a new Job name. Other immutable or invalid changes fail server validation without deleting/recreating a workload. Updates retain resource versions; pruning requires the inspected UID and resource version and runs only after successful creates/updates. DELETE dry-runs include dryRun in the DeleteOptions body, as required when sending a body.

This is not a transaction across Kubernetes resources. Concurrent edits or transport failures during commit can still interrupt the operation; stale writes fail rather than overwriting changes, and no pruning follows a failed create/update.

Validation:

• 74 admission/reconciliation/runtime-cleanup tests pass after updating to main; adapter typecheck and the structured-error audit pass. The added manifest-inventory regression fails against the previous code, and foreign project/runtime ownership still blocks cleanup.
• Three real K3s tests exercise all six resource kinds: create, unchanged reapply, update, Service-IP retention, owned-only prune, immutable/schema rejection and reserved pod ownership rejection. The fixture uses a pinned image, verified TLS, isolated namespaces and no worker nodes or external infrastructure.
• Against the original PR, two of the K3s regressions fail: a ConfigMap is changed before a later immutable Deployment error, and reserved pod labels are accepted. Both now pass.
• The K3s fixture is removed after testing and is added to PR CI and the release gate. Changelog updated.

The three real K3s checks passed in CI on the previous head. They were not repeated locally during this update because the Docker daemon is unavailable; the new head reruns the same CI suite.

[Hydralerne]

This is a useful foundation for #1039, and the PR clearly states that deployment/UI wiring is deferred. It should remain open, but the admission and reconciliation boundary needs two fixes before merge:

1. Reserved ownership keys and finalizers are only checked on the outer object. I ran admitProjectManifests with a Deployment whose spec.template.metadata.labels contains openship.io/deployment: existing-release and app.kubernetes.io/managed-by: openship, with the matching reserved selector and a custom pod finalizer. It is accepted unchanged. Existing runtime Services and pod lookups select openship.io/deployment, so these pods can enter an existing managed workload's selector; the finalizer can also prevent cleanup. Validate pod metadata/selectors, and both Job and pod template metadata inside CronJobs. Enforce the ownership boundary at every controller-generated object, not only the parent.
2. The fake API accepts updates Kubernetes rejects. applyProjectManifests blindly PUTs every changed owned object. Job pod templates and Deployment selectors are immutable, so the advertised update path can fail after earlier objects were already changed. Define explicit per-kind behavior for immutable changes and test it against a real API server. At minimum, preflight unsupported changes before making mutations; do not silently delete/recreate workloads to get around immutability.

The first finding is reproduced against this branch's actual admission function. No user endpoint exposes it yet, so this is a pre-merge blocker, not evidence of a live tenant compromise. Please add negative admission cases and a real k3s apply/update/prune test covering these boundaries.

[Hydralerne]

Applied the ownership and reconciliation fixes directly to this branch and verified this exact commit. Manifest changes now preflight all API writes and pruning before mutation; updates and deletes carry concurrency preconditions, and reserved OpenShip ownership metadata is rejected throughout workload templates. Changed Jobs require a new name. This remains a manifest foundation, not a cross-resource transaction or a deployed upload flow.

Validation: 71 unit/runtime checks plus 3 real K3s tests passed locally, including immutable-update failure before earlier resources change and owned-only pruning. All 21 CI checks pass, including the new Kubernetes manifests job. Temporary test infrastructure was removed.