[Feature/Edge Case] Dynamic Cross-model/Cross-Platform Relations

Solutions Engineering reached out to request additional Charm QA runs of their `hardware-observer` charm in [this Mattermost thread](https://chat.canonical.com/canonical/pl/1s9mt4o3qbgjfqd7ywn45j1k8a)

It is a public/listed charm, and we have run tests for it before, but they wanted new runs. I explored running the Charm QA workflow manually:
https://github.com/canonical/charm-integration-testing/actions/runs/26944426036/job/79493804093

The bundle builder failed with

```
ERROR Error in test_build_bundle: bundle_builder_x.bundle_builder.UncompletableBundleError: Could not build a complete valid bundle: Cannot fulfill charm endpoints: opentelemetry-collector:grafana-dashboards-provider, opentelemetry-collector:grafana-dashboards-provider
```

I think the interesting edge case here is that `hardware-observer` and `opentelemetry-collector` are both machine charms, but then `opentelemetry-collector` has requirements that are only provided by K8s charms (as far as I can tell). So both the target and neighbor charms are machine charms, meaning we wouldn't naturally create a K8s-CMR, but a K8s environment is needed nonetheless to fulfill endpoints as determined at the bundle-building stage. Thus, we would need to dynamically be able to request environments after the run has started, which is certainly a headache.

This is probably too much effort for too little reward, but I thought it would be worth filing an issue for the sake of completeness.

Start by reproducing the Charm QA workflow run for hardware-observer and inspect test_build_bundle, especially the bundle_builder failure involving opentelemetry-collector:grafana-dashboards-provider. Trace how the workflow selects environments for machine charms and how endpoint requirements are resolved. Done means the workflow can request the required Kubernetes environment dynamically and complete QA runs for this cross-platform relation.

Written by the indexing model from the issue text.