fix(observability): schedule pyroscope on frankfurt as intended

[ExtraToast]

Replaces #761, which GitHub auto-closed when its stacked base branch was deleted on merge of #760. Same commit, now based on main.

Problem

pyroscope-0 has been running on enschede-gtx-960m-1 — a 2015 laptop — for 109 days, despite the HelmRelease declaring frankfurt.

Root cause

The selector was at the top level of values:

values:
  pyroscope:
    replicaCount: 1
    ...
  nodeSelector:              # <-- discarded
    personal-stack/site: frankfurt

The chart reads scheduling keys under its own pyroscope key. A top-level nodeSelector is silently dropped, so the pod was scheduled with no constraint at all and landed wherever the scheduler put it. This is the same nesting trap the alloy, tempo and loki releases hit.

Change

• nodeSelector moves under pyroscope, where the chart reads it.
• placement_intent.frankfurt_only gains a pyroscope entry so the inventory states the same intent as the release.

Why it matters here

The 960M node's entire CPU baseline is 1160m, of which only 284m is workloads — the rest is host daemons. pyroscope accounted for roughly 17m of steady CPU and 120 MiB on that node, and it was never meant to be there.

Operational note — this needs a manual step after merge

The existing 20Gi volume cannot follow the pod:

data-pyroscope-0  sc=local-path  RWO
PV nodeAffinity: kubernetes.io/hostname In [enschede-gtx-960m-1]

local-path with reclaimPolicy: Delete. The StatefulSet will stay Pending until the PVC is deleted so a fresh volume provisions on frankfurt, which discards accumulated profile history. Profiles are short-horizon debugging data, so the retention loss is accepted. Frankfurt has 236 GiB free.

Validation

• All five render scripts run clean (no rendered-output drift).
• kubectl kustomize platform/cluster/flux/clusters/production builds.
• cd platform/tests && node --test — 56/56 pass.