[Story]: Customer-facing residency policy controls

## Summary
Build customer-facing controls for selecting a residency policy (e.g. EU-only, no restriction) at the org or BU level, wired to the enforcement in g4s1.

## Intent / Source of truth
Region selection needs to be a customer-controllable setting, not an engineering-only flag, per the Windsurf competitive precedent named in the epic. Part of [Epic] Data residency selection and enforcement.

## Scope
- [ ] Residency-policy setting in the org/BU admin UI and API
- [ ] Effect of the setting clearly surfaced (which models remain available under a given residency choice, per g4s2's documentation)

## Out of scope
- Per-request residency override (policy is set at org/BU level, not per-call)

## Verification
A test org configured for EU-only residency shows the correct restricted model list and confirms g4s1's routing enforcement matches the selected policy.

## Risk assessment
The UI must not let a customer select a residency guarantee for a model that can't actually honor it (per g4s2) — the available-model list must be dynamically filtered, not just documented separately from what the UI allows.

## AI Usage Declaration
Drafted with AI assistance during the 2026-08-13 cross-repo backlog consolidation and enterprise-readiness research. A human owns intent, verification and consequences.

Start by reading the g4s1 enforcement and g4s2 documentation referenced in the issue; no files or test entry points are named. Trace the org/BU admin UI and API entry points, then verify with a test org that EU-only selection filters unavailable models and matches g4s1 routing enforcement.

Scritto dal modello di indicizzazione a partire dal testo della issue.