prewarm: render no PriorityClass — a pool release is namespaced; take the class name from pool.prewarm.priorityClassName (the platform ships it) #15

Problem

pool.prewarm (0.4.0) rendered a cluster-scoped PriorityClass beside the placeholder Job. A pool release is delivered by the organisation's
tenant ServiceAccount, whose rights are namespaced; the install failed on the PriorityClass (InstallFailed) and the pool never came up. The
chart must not render cluster-scoped objects.

Solution

Shipped in #16 → 0.4.1: the chart renders no PriorityClass. The Job's priorityClassName comes from pool.prewarm.priorityClassName
(default agent-platform-prewarm-placeholder, the class the agent-platform release ships with its model-serving component —
giantswarm/agent-platform#539); an empty name is refused at render, since a pod without a class has priority 0 and no workload preempts it.
make verify holds every object of a render to the release namespace. Where the class does not exist on the cluster the pool installs all
the same: admission refuses the Job's pod, no node launches, the Job ends at its deadline and removes itself.

Acceptance criteria

• With prewarm.enabled: true the chart renders the Job with priorityClassName from the value and no PriorityClass (goldens updated) — hack/fixture/goldens/prewarm.yaml.
• A pool release with prewarm.enabled: true contains only namespaced objects (a test asserts no cluster-scoped kind in the render) — hack/check_render.py --namespace, run by make verify on every render.
• README documents the value and the dependency — Prewarming the first node.