Sticky routing for ai_id / session_id

VZ runtime pods are stateful: each ai_id owns a kernel session in memory. If two requests for the same ai_id land on different pods, the second request talks to a fresh, partially hydrated kernel — your protocols and session memory will look inconsistent.

Production overlays must enforce sticky placement keyed by ai_id (and by session_id within an ai_id), via Ingress hash policy or via a sidecar router. The Portal BFF preserves ai_id and session_id in the upstream URL exactly so a sticky Ingress sees them.

See docs/deployment/routing.md for the cluster-side configuration.