[Ticket]: Give the Next usage proxy a client certificate

### Type
Feature

### Summary
Present a client certificate from the console's Next server when proxying to the usage query listener.

### Intent
So the console can reach a listener that requires mTLS. Without it the proxy cannot connect at all.

### Source of truth (links)
- #347 (usage service split TLS surface)
- `crates/lightbridge-authz-core/src/server.rs`, `build_mtls_config`
- `apps/console/src/server/proxy.ts`

### Current Behavior
The proxy performs a plain HTTPS request - verified: there is no cert, agent, or TLS option anywhere in `src/server/`. The usage query listener on 3006 requires and verifies a client certificate.

### Expected Behavior
The proxy presents a CA-signed client certificate and reaches the query listener.

### Acceptance Criteria
- [ ] Cert and key supplied by configuration, never committed
- [ ] A missing or invalid cert produces an explicit, logged failure - never a silent fallback to an unauthenticated call
- [ ] Cert paths are validated at startup, matching the backend's fail-fast posture
- [ ] Local dev documented, including the self-signed CA

### Out of Scope
Changing the usage service's mTLS requirement, which is deliberate.

### Technical Context
The deployed `authz-tls` cert already carries both `serverAuth` and `clientAuth`, so no new CA is needed. This authenticates 'a legitimate lightbridge workload', not a specific caller.

### Risks
Fail-closed is mandatory here: a rejected or missing client cert must resolve to unavailable, never to an unauthenticated retry. This is the highest-yield review question in this repo.

### Test Plan
Integration test against the real listener: valid cert succeeds, missing cert fails explicitly, expired cert fails explicitly.

### Verification evidence
- [ ] Test added and proven to fail before the change
- [ ] `just all-checks` green
- [ ] Every new or changed `src` file is <= 200 LoC

### Human accountable owner
@stephane-segning

### AI Usage Declaration
Ticket drafted with AI assistance from a verified repo audit.
Structure and estimates drafted with AI from a verified repository audit (file
line counts, config keys, and dependency state were read from the actual tree,
not assumed). A human owns intent, scope, and the release commitment.

### Human verification completed
- [ ] I can explain this work without referring to the AI-generated text
- [ ] Acceptance criteria are testable
- [ ] Source of truth is a real link, not boilerplate

Governance: https://adorsys-gis.github.io/ai-governance/