[FEATURE] Create contractual object names for Provider-based Patching

Goal

Create a naming contract for Core Components to enable Provider patches to core objects by name.

Owner: kustomize release workstream (#3169). Consumers: GKE workstream (ai-on-gke/substrate-gke#152, ai-on-gke/substrate-gke#156) and any other provider Component.

Establish a list of what core promises not to rename. It contains only object, container, and volume names, so it carries no provider content.

Specification.

Object (namespace `ate-system`)	Stable names
DaemonSet `atelet`	Containers `atelet`, `objectstore-plugin`; volumes `image-credential-provider-bin`, `image-credential-provider-config`; `spec.template.spec.tolerations` list
Deployment `ate-api-server`	Containers `ate-api-server`, `objectstore-plugin`; ServiceAccount `ate-api-server`
Deployment `atenet-router`	Containers `atenet-router`, `envoy`; pod label `app: atenet-router`; container port `envoy-metrics`
ConfigMap `ate-otel-config`	All keys in #3172
ConfigMap `ate-api-server-envvars`	All keys in #3172
Secret `ate-api-server-secret-envvars`	All keys in #3172

Rules for patches against these targets:

Tolerations have no merge key. Providers append with a JSON 6902 add to /spec/template/spec/tolerations/-, never a strategic-merge list, which would replace atelet's own ate.dev/sandboxClass toleration.
Arguments. Core does not ask providers to patch container args. A strategic-merge patch replaces the whole list, dropping core's arguments, so settings that affect arguments are exposed through environment variables or settings objects.

Enforcement.

Core CI renders the install and asserts every listed name exists, so a rename fails in core.
Provider CI renders its Component against each pinned core release.

Related: #2760 (toleration list target), #2669 and #3667 (credential-provider volumes).

Parent Issue: #3160