k8s charm blocked on OpenStack test environments: Cilium/Fan networking (ftun0) port conflict not mitigated in environments.yaml

*This issue was generated with AI assistance (GitHub Copilot) from automated CI test failure triage.*

## Bug Description

The k8s charm becomes permanently `blocked` when deployed on the `ps6-sqa-prod_charm_qa_openstack` (and likely `ps7-sqa-prod_charm_qa_openstack`) test environments because Cilium's VXLAN tunnel conflicts with Juju's Fan networking interface (`ftun0`) on the workload model. Both interfaces use the same destination port, and Cilium refuses to come up while the conflict persists — the `network` feature never reports ready, so `test_deploy` times out after 15 minutes.

Repository search confirms neither `static/environments.yaml` nor any test-plan/fixture code in this repo sets `container-networking-method` or `fan-config` on the OpenStack environments:
- `container-networking-method`: 0 matches repo-wide
- `fan-config`: 0 matches repo-wide
- `ps6-sqa-prod_charm_qa_openstack-1/2` has no `model-config` block at all
- `ps7-sqa-prod_charm_qa_openstack-1/2` has a `model-config` block, but it only sets proxy/logging options — no networking-method override

This matches a known, previously reported conflict: [canonical/k8s-operator#392](https://github.com/canonical/k8s-operator/issues/392), which documents the workaround:
```
juju model-config container-networking-method=local fan-config=
```
and points to the OpenStack charm how-to guide: https://documentation.ubuntu.com/canonical-kubernetes/latest/charm/howto/openstack/

## To Reproduce

1. Deploy the `k8s` charm (channel `1.32/stable`, revision 1921) alongside `etcd` (latest/beta rev 706) and `containers-easyrsa` (latest/stable rev 441) on the `ps6-sqa-prod_charm_qa_openstack` environment, without setting `container-networking-method=local` / clearing `fan-config` on the model.
2. Wait for `test_deploy` to reach idle.

Test Observer: https://test-observer.canonical.com/#/charms/337980?testExecutionId=337614&testResultId=12683772
Workflow run: https://github.com/canonical/charm-integration-testing/actions/runs/30833558959

## Relevant log output

```
adaac62f-4a87-46fa-8588-f458d5533f7a: unit-k8s-0 2026-08-03 16:52:44 ERROR unit.k8s/0.juju-log server.go:405 etcd:4: Feature 'network' enabled=True,deployed=False,ver=1.17.12-ck0-static,updated_at=2026-08-03 16:52:36+00:00: Failed to deploy Cilium Network, the error was: interface ftun0 uses the same destination port as cilium. Please consider changing the Cilium tunnel port
adaac62f-4a87-46fa-8588-f458d5533f7a: unit-k8s-0 2026-08-03 16:52:44 ERROR unit.k8s/0.juju-log server.go:405 etcd:4: Failed features reported: Feature 'network' is not ready

[repeats every 30-60s for the full 15-minute deploy window, ending with:]

juju.backend.JujuWaitTimeoutError: Timed out while waiting for applications: [active], units: [active], unit agents: [idle] (applications: ['k8s', 'neighbor', 'target'], unit agents: ['neighbor/0', 'target/0'], units: ['k8s/0', 'neighbor/0', 'target/0'])

App Version Status Scale Charm Channel Rev Exposed Message
k8s 1.32.13 blocked 1 k8s 1.32/stable 1921 no Feature 'network' is not ready
```

## Additional context

Note that in this same execution, `neighbor` (containers-easyrsa) and `target` (etcd) also failed to get their units running, but for an unrelated, separate reason — a transient OpenStack image-metadata timeout (`radosgw.ps6.canonical.com` Swift/Keystone catalog `i/o timeout`) blocked machine provisioning for those two applications. That appears to be a transient infrastructure issue rather than a configuration problem, and is not the subject of this report — flagging it here only to avoid confusion when reading the linked test execution's full `test_deploy` failure message, which references all three applications.

The Cilium/`ftun0` conflict specifically affects only the `k8s` application and is expected to recur deterministically on every run against this environment family until the model configuration is updated.

Start with static/environments.yaml and inspect the ps6-sqa-prod_charm_qa_openstack and ps7-sqa-prod_charm_qa_openstack entries, then trace the test_deploy setup for model configuration. Confirm the OpenStack environments apply the required networking settings and run the affected deployment test; done means the k8s network feature becomes ready and test_deploy reaches idle without the ftun0 conflict.

Written by the indexing model from the issue text.