[Epic]: The default install and the local stack behave like production

### Summary

Production is correct; the **shipped artifact and the local stack are not**. `helm install charts/lightbridge-authz-stack` with `global.tls.enabled=true` cannot satisfy its own mTLS defaults, and the compose stack still points every resource server's `jwks_url` at Keycloak while prod points them at `authz-idp`.

### Intent

"Works locally" should mean the same trust and TLS topology as production. Today it means a different one — and that gap has already produced a real defect, not just friction: **a local-only topology was written into ADR-0030 and two docs as though it were a *platform* limitation.** A divergent dev environment does not merely slow people down; it manufactures false facts about the system that then get cited as decisions.

### Children

- **#614** — the local stack's `jwks_url` points at Keycloak (`.docker/authz/container.yaml:117` carries an explicit "⚠️ LOCAL-STACK DIVERGENCE … tracked follow-up" comment), while prod validates against `authz-idp`
- **#615** — `charts/lightbridge-authz-stack/templates/global-tls-job.yaml` issues five independent self-signed leaves and emits no `ca.crt`, so mTLS defaults cannot be satisfied by a default install

### Acceptance Criteria

1. A default `helm install` of `charts/lightbridge-authz-stack` with `global.tls.enabled=true` comes up healthy with mTLS actually verifying — no manual certificate step, no documented workaround.
2. The local compose stack validates every resource server's tokens against **`authz-idp`**, matching prod. The `LOCAL-STACK DIVERGENCE` comment at `.docker/authz/container.yaml` is deleted because it is no longer true.
3. A login against the local stack reaches both the human and API planes, proven by an integration test — the same assertion #510 makes for prod.
4. ADR-0030 and the two docs that recorded the local-only topology as a platform limitation are corrected, each naming what was actually local-only.

### Out of Scope

- Production trust-root work — that is `#510`, which this complements rather than duplicates (#510 is prod; this is everything we ship and everything we run locally).
- The internal CA's own design.

### Technical Context

⚠️ AC 4 is the one most likely to be skipped and is the reason this epic exists. Fixing the config without correcting the docs leaves the false platform-limitation claim in an **Accepted ADR**, where it will be cited again.

### AI Usage Declaration

Grouping identified and epic drafted by Claude Opus 5 during the 2026-09-01 triage sweep; the divergence comment at `.docker/authz/container.yaml:117` and the five-leaf TLS job were verified on `origin/main`. AI output is not truth; the owner verifies.

Start with child issues #614 and #615, reading .docker/authz/container.yaml:117 and charts/lightbridge-authz-stack/templates/global-tls-job.yaml. Compare the local topology with production and the assertions in #510, then identify the integration test entry point. Done means the default TLS-enabled install verifies mTLS, local login reaches both planes, and ADR-0030 plus the two affected docs no longer describe local behavior as a platform limitation.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.