Pin FMA+KEDA workloads to a target node for benchmarking

[dumb0002]

Confines an FMA+KEDA benchmark to a single node — including a tainted, admin-reserved one — so load generation and other tenants can't perturb the measurements.

Node name, label, and tolerations are set in one place: the new top-level nodePinning block in config/templates/values/defaults.yaml. Filling it in places the FMA launchers, the FMA requester, and EPP on that node; no per-scenario edits. The block is inert while enabled: false.

nodePinning:
  enabled: true
  nodeName: <node>
  nodeLabel: <key>
  nodeLabelValue: <value>
  tolerations:
    - key: <taint-key>
      operator: Equal
      value: <taint-value>
      effect: NoSchedule

FMA launchers and requester

• nodeName pins to a named node instead of auto-selecting. Required for a tainted node: the auto-scan ranks on free GPU/CPU and does not consider taints, so it can pick a node whose pods never schedule. A named node is validated (exists, carries the selection label, has free GPUs) but never labeled or otherwise mutated — it is assumed prepared by whoever owns the cluster. A node with taints but no fma.tolerations warns rather than failing silently.
• nodeLabelValue makes the selection label value configurable; previously hardcoded to 'true'.
• fma.tolerations is applied to both the launcher podTemplate (launcher pods are created by the FMA controller from it) and the requester Deployment.
• Teardown no longer strips the selection label when nodeName is set, which would otherwise break subsequent runs against an admin-prepared node.

EPP

_apply_epp_node_pinning() in render_plans.py injects EPP's placement from the same block. The router chart exposes affinity and tolerations for EPP but no nodeSelector, so node selection becomes a nodeAffinity term there while the FMA requester uses nodeSelector — different syntax, same effect. Adding router.epp.nodeSelector would be silently ignored, which is why this is done in the renderer rather than left to scenario authors.