juju-jimm-k8s (auto-injected as juju-dashboard-k8s's controller satisfier) fails oauth-relation-changed hook with hydra

## Summary

When a test plan uses `juju-dashboard-k8s` as target or neighbor, the bundle
builder satisfies its non-optional `controller` (interface `juju-dashboard`)
endpoint by auto-injecting `juju-jimm-k8s` (the only charm in Charmhub's
search space that exposes a `dashboard` endpoint on this interface). Per the
existing `static/charm-overrides/juju-jimm-k8s.yaml` override (track 3+
block), this in turn requires `oauth` (features: `[tls]`), which pulls in
`hydra`, `openfga-k8s`, `pgbouncer-k8s`, `postgresql-k8s`, and
`self-signed-certificates`.

In this configuration, `juju-jimm-k8s`'s unit consistently ends in
`error` status with `hook failed: "oauth-relation-changed"` for the
`hydra:oauth` relation, well past the 15-minute `wait_idle` timeout. All
other applications in the bundle (including the actual target/neighbor pair
under test) reach `active` normally.

## Suspected root cause

`static/charm-overrides/juju-jimm-k8s.yaml`'s track 3+ block pins
`dns-name: ['jimm-test.local']` as a fixed placeholder config value to
satisfy solver constraints. `jimm-test.local` is not a resolvable/reachable
hostname in the ephemeral k8s test model, so when `hydra`'s OAuth handshake
with `juju-jimm-k8s` attempts to validate/reach the configured issuer or
redirect URL, the hook fails. This is plausibly an environmental limitation
of testing an OAuth-style interface without real DNS, rather than a defect
in `traefik-k8s` or `juju-dashboard-k8s`.

## Reproduction

Encountered while running `traefik-k8s-testing/test_plan-10-378.md`
(`traefik-k8s:ingress` <-> `juju-dashboard-k8s:ingress`) after fixing an
unrelated `test_build_bundle` failure (see
`static/charm-overrides/juju-dashboard-k8s.yaml`, added in this same
session). With that fix in place, `test_build_bundle` and the actual
`target:ingress <-> neighbor:ingress` relation both work correctly, but
`test_deploy` times out because of this collateral `juju-jimm-k8s` failure.

```
juju status
App Status Charm Channel Rev Message
juju-jimm-k8s error juju-jimm-k8s 3/stable 105 hook failed: "oauth-relation-changed"
```

## Impact

Any test plan that pulls in `juju-jimm-k8s` as a satisfier for
`juju-dashboard-k8s`'s (or any other charm's) `controller`/`juju-dashboard`
interface endpoint will hit this same collateral failure at `test_deploy`,
independent of whether the actual endpoint under test works correctly.

## Suggested next steps

1. Confirm whether `hydra`'s OAuth flow with `juju-jimm-k8s` can be made to
work with a placeholder/non-resolvable `dns-name`, or whether the
`juju-jimm-k8s` override needs a different fixed config (e.g. a
resolvable in-cluster hostname) for the `oauth`-with-tls case.
2. Alternatively, consider whether `bundle_builder_x` should support
synthesizing the real controller-model SAAS-offer relationship for
`juju-dashboard`-interface `controller` endpoints (see also #657), which
would avoid needing `juju-jimm-k8s` (and its full downstream dependency
chain) as a stand-in entirely.

Related: #657 ("Juju-dashboard must be deployed in controller model ...
currently unsupported").

Start with test_plan-10-378.md, static/charm-overrides/juju-jimm-k8s.yaml, and the test_deploy path; reproduce the oauth-relation-changed failure with juju status and inspect the dns-name configuration. Compare the override approach with the controller-model SAAS-offer concern in #657. Done means the bundle deploys without the collateral juju-jimm-k8s error and the target relation still reaches active.

Written by the indexing model from the issue text.