grafana-k8s: missing charm override for `provide-cmr-mesh`/`require-cmr-mesh` causes duplicate relation in generated bundle

**Note: Filed with AI assistance (GitHub Copilot) by @canonical-vultaire**

---

## Summary

`test_deploy` fails for any test plan that includes `grafana-k8s` (track `12.4/stable`) in a CMR K8s/K8s environment because the generated bundle contains a duplicate relation entry. This is the same root cause as #668, which was fixed by PR #666 for `alertmanager-k8s`, `catalogue-k8s`, `opentelemetry-collector-k8s`, and others — but `grafana-k8s` was not included in that fix.

## Failing test

- **Artefact**: `katib-controller` rev 1360 (track `0.19/beta`)
- **Test plan**: `integration/grafana-agent-k8s:logging-provider/loki_push_api/katib-controller:logging`
- **Test**: `test_deploy`
- **Environment**: `juju:3/stable ubuntu:24.04 cmr/kubernetes/kubernetes` (amd64)

## Error

```
jubilant._juju.CLIError: Command ['juju', 'deploy', '--model',
'charmqa-30878141375-70878716:charmqa-30878141375-38588733',
'/home/ubuntu/snap/juju/common/tmp1_p_6xo_/_temp.charm', '--force', '--trust']
returned non-zero exit status 1.

Stderr:
ERROR cannot deploy bundle: the provided bundle has the following errors:
relation ["grafana-k8s-provide-cmr-mesh-cross-model-mesh-offer:provide-cmr-mesh"
"grafana-k8s:require-cmr-mesh"] is defined more than once
```

The integration list for this test plan includes the self-referential CMR mesh entry:
```
grafana-k8s:provide-cmr-mesh/cross_model_mesh/grafana-k8s:require-cmr-mesh
```

`grafana-k8s` rev 193 (`12.4/stable`) exposes both `provide-cmr-mesh` (provides) and `require-cmr-mesh` (requires) without `optional: true` upstream. The bundle builder therefore creates both a CMR offer-and-consume relation and a direct in-model relation for the same pair, producing a duplicate in the generated YAML.

## Persistence

Same error across 3 consecutive runs (all `katib-controller` rev 1360):

| Test Execution | Test Result | CI Run |
|---|---|---|
| [680886](https://test-observer.canonical.com/#/charms/409775?testExecutionId=680886&testResultId=12699279) | 12699279 | — |
| [680890](https://test-observer.canonical.com/#/charms/409775?testExecutionId=680890&testResultId=12699298) | 12699298 | — |
| [680894](https://test-observer.canonical.com/#/charms/409775?testExecutionId=680894&testResultId=12699355) | 12699355 | https://github.com/canonical/charm-integration-testing/actions/runs/30878141375 |

All subsequent tests in each run were skipped due to `test_deploy` failing.

## Root cause

`static/charm-overrides/grafana-k8s.yaml` does not exist. PR #666 added overrides for other CMR mesh charms but omitted `grafana-k8s`.

**Note**: `parca-k8s` also appears with a self-referential CMR mesh entry (`parca-k8s:provide-cmr-mesh/cross_model_mesh/parca-k8s:require-cmr-mesh`) in the same test plan's integration list and likewise has no override file — it may produce the same failure in other test plans.

## Fix

Add `static/charm-overrides/grafana-k8s.yaml` following the same pattern as `alertmanager-k8s.yaml` from PR #666, marking `provide-cmr-mesh` (provides) and `require-cmr-mesh` (requires) as `optional: true` for the tracks that include these endpoints (at minimum `12.4`). Consider also adding a `parca-k8s.yaml` override at the same time.

Start with static/charm-overrides/alertmanager-k8s.yaml and compare its CMR mesh override pattern with the generated bundle failure described for grafana-k8s. Add the corresponding grafana-k8s override for the affected tracks, and consider the noted parca-k8s case. Run the failing test_deploy plan to confirm the duplicate relation is removed.

Written by the indexing model from the issue text.