vault-k8s rejects glauth-k8s cert: "common name ... not allowed by this role" (test_deploy timeout)

**Note: This issue was generated with AI assistance (GitHub Copilot) based on automated log analysis and triage.**
Filed by @canonical/solutions-qa

`test_deploy` (test plan `integration/vault-k8s:vault-pki/tls-certificates/glauth-k8s:certificates`) times out — `neighbor` (glauth-k8s rev 57) never leaves `waiting: Missing TLS certificate and private key`:
```
juju.backend.JujuWaitTimeoutError: Timed out while waiting for applications: [active], units: [active],
unit agents: [idle] (applications: ['neighbor'], units: ['neighbor/0'])
```

`unit.target/0.juju-log` (vault-k8s rev 565, `pki_ca_common_name: charmqa`), repeated 3x:
```
WARNING [vault_client] PKI error while signing certificate: common name
neighbor.charmqa-30688395229-36042055.svc.cluster.local not allowed by this role,
on post .../v1/charm-pki/sign/charm
{"event": "certificate_denied", "code": "102", "common_name": "neighbor.charmqa-30688395229-36042055.svc.cluster.local"}
```

`unit.neighbor/0.juju-log` (glauth-k8s rev 57), repeated each hook:
```
The certificates data is not ready.
Deferring .
```

**Steps to reproduce:** Deploy vault-k8s rev 565 (`pki_ca_common_name: charmqa`) as `target`, integrate `target:vault-pki` ↔ `neighbor:certificates` with glauth-k8s rev 57, wait for `neighbor` to go active.

**Test Observer:** https://test-observer.canonical.com/#/charms/296340?testExecutionId=668555&testResultId=12670887

Start by rerunning the test_deploy plan at integration/vault-k8s:vault-pki/tls-certificates/glauth-k8s:certificates with the listed charm revisions and inspect the target and neighbor hook logs. Trace the certificate request for neighbor.charmqa-30688395229-36042055.svc.cluster.local and the role configuration used by the charm-pki endpoint. Done means the certificate is accepted and neighbor leaves “Missing TLS certificate and private key” without timing out.

Written by the indexing model from the issue text.