[Ticket]: Console proxy dials public ingress for in-cluster services

## Type

Technical debt / architecture

## Summary

The console's server-side proxy dials `https://self-service.ai.camer.digital` — a **public** ingress — for `backendUrl`, `budgetUrl` and `usageUrl`, even though it runs in the `converse` namespace alongside `lightbridge-api`, `lightbridge-budget`, `lightbridge-idp` and `lightbridge-usage`.

Expected result:
> Server-to-server traffic stays inside the cluster instead of hairpinning out through public DNS, TLS and the ingress and back in.

## Intent

These values were **inherited, not chosen**. `environments/prod/values/console-ui.yaml` says so in its own comments:

> `backendUrl / apiBasePath`: **SAME host + RPC prefix converse-ui.yaml uses** (`EXPO_PUBLIC_BACKEND_URL` / `EXPO_PUBLIC_API_BASE_PATH`)
> `usageUrl`: **same host as `EXPO_PUBLIC_USAGE_URL`**, for feature parity with self-service's usage dashboard

`converse-ui` is the Expo app: a **browser** client, which had no alternative, because a browser cannot resolve `*.converse.svc`. The console is architecturally different — ADR 0009 Decision 3 makes its Next server the only exposed origin and has it proxy every backend server-side. That constraint does not transfer, and copying the values carried it across anyway.

Nothing is broken today for the rpc/budget legs; this is about the shape being accidental rather than intended.

## Source of truth (links)

- https://github.com/ADORSYS-GIS/converse-frontends/blob/main/docs/adr/0009-nextjs-console-replacement.md (Decision 3 — server-side proxy, no backend exposed to the browser)
- `ai-helm-values` `environments/prod/values/console-ui.yaml` (the inheritance comments quoted above)
- `ai-helm-values` `environments/prod/values/lightbridge-app.yaml` (`usage_service.base_url` already uses the in-cluster form)

## Current Behavior

Each RPC from the console leaves the pod, exits the cluster, resolves public DNS, terminates TLS at Traefik, passes a `StripPrefix` middleware that removes `/api/v2`, and re-enters the cluster to reach `lightbridge-api` — which serves the unprefixed `/rpc/{op}` directly.

That path depends on public DNS, the ingress, the public certificate and a prefix-stripping middleware **for traffic between two pods in the same namespace**. Any of them degrading takes the console down while both services are perfectly healthy.

Note `lightbridge-app.yaml` already does the opposite for its own dependency: `usage_service.base_url: "https://lightbridge-usage.converse.svc:3006"`. The in-cluster convention exists; the console just isn't following it.

## Expected Behavior

`backendUrl`, `budgetUrl` and `usageUrl` point at in-cluster service URLs. Consequences worth stating:

- `apiBasePath` can likely return to `/` — console-ui.yaml's own comment says that default "only applies when backendUrl points directly at authz-api with no gateway in front", which is exactly what this change creates.
- The `StripPrefix` middleware stops being on the console's critical path.
- Public ingress remains for the **browser**-facing origin (`console.ai.camer.digital`), which is unaffected.

## Acceptance Criteria

- [ ] Each leg is verified individually: in-cluster service name, port, and whether that listener requires client certificates.
- [ ] `apiBasePath` is re-derived rather than assumed.
- [ ] A leg is only repointed once proven reachable — no big-bang switch of all three.
- [ ] The public origin for browser traffic is untouched.

## Out of Scope

- The usage leg's mTLS work (#275) — a prerequisite for that leg, being built separately.

## Open question — must be answered before implementing

**Do `lightbridge-api` and `lightbridge-budget` require client certificates on their in-cluster ports?** The usage query listener on 3006 demonstrably does (`insecure_skip_verify: false`, `client_cert_path`). Whether the other two do is **not verified** — the `tls:` blocks in `lightbridge-app.yaml` were not traced to a conclusion. If they do, this ticket depends on #275's dispatcher generalising beyond the usage leg, which would be an argument for building it that way rather than usage-only.

## Technical Context

`apps/console/src/server/{env,proxy-target}.ts`, `ai-helm-values` `environments/prod/values/console-ui.yaml`.

## Human accountable owner

@stephane-segning

## AI Usage Declaration

Raised from the owner's question "why use self-service.ai.camer.digital and not the in-cluster svc url?". The inheritance explanation is quoted from the values file's own comments; the mTLS status of the api/budget legs is explicitly flagged as unverified rather than assumed either way.

Start with apps/console/src/server/{env,proxy-target}.ts and environments/prod/values/console-ui.yaml, then compare lightbridge-app.yaml's usage_service.base_url. Verify each service name, port, and client-certificate requirement individually before changing a leg. Done means the three server-side targets use reachable in-cluster URLs, apiBasePath is re-derived, and the browser-facing public origin is unchanged.

Escrita pelo modelo de indexação a partir do texto da issue.