Remove Prometheus Job→App Relabeling

Remove the legacy `job → app` metric relabeling block from every Prometheus
scrape config and ServiceMonitor so downstream queries can rely on the native
`job` label.

For each repository:
1. Find every Prometheus configuration source:
   - `ServiceMonitor` and `PodMonitor` CRDs (kube-prometheus-operator); look for
     `metricRelabelings:` under each endpoint
   - Raw Prometheus configs (`prometheus.yml`, `scrape-config.yaml`); look for
     `metric_relabel_configs:` blocks
2. In each, locate relabeling entries that match this shape:
     sourceLabels: [job]      # or source_labels in raw configs
     targetLabel: app         # or target_label
     action: replace
   and remove the entry.
3. If the surrounding `metricRelabelings` / `metric_relabel_configs` list becomes
   empty, remove the empty list key as well.
4. Leave all other relabel rules untouched; only this specific `job → app` rule
   is targeted.
5. Skip files that do not contain the matching rule.

In the PR body, list the dashboards, alerts, and recording rules that should be
audited for `{app=...}` selectors so they can be migrated to `{job=...}` before
the change rolls out.

The Problem

At some point someone added a `metric_relabel_configs` block that copied `job` into a label called `app`. Years later, dashboards, alerts, and recording rules grew up using both labels interchangeably, which means renaming a service breaks half of one and not the other, and queries like `sum by (app)` and `sum by (job)` silently return different shapes.

The fix is mechanical: remove the relabel block everywhere and let downstream queries fall back to the native `job` label. But it lives in dozens of ServiceMonitor manifests and scrape configs scattered across infra repos.

What Tidra Does

1. Finds every ServiceMonitor, PodMonitor, and raw Prometheus scrape config across repos
2. Detects metric_relabel_configs entries that map sourceLabels: [job] to targetLabel: app
3. Removes the matching block (and the surrounding metric_relabel_configs list if it becomes empty)
4. Leaves unrelated relabel rules untouched
5. Opens one PR per repo with a before/after diff and a note about which dashboards/alerts to verify

Before & After

Customization Tips

• Variants: Some configs use metric_relabel_configs (raw Prometheus), others metricRelabelings (Operator CRDs). Both are handled.
• Dashboard sweep: Pair this with a Grafana dashboard sweep to swap {app=...} selectors for {job=...} before merging.
• Recording rules: Recording rules emitting app labels need separate cleanup, include them in the prompt if they exist.