Update Runtime Policy

Room-wide fan-out policy, plus the tree-wide container spend ceiling.

TOS-2393: deliberately carries NO per-chat/per-payer spend field. It used to accept max_chat_spend_usd, but that let any caller of this general-purpose endpoint silently rewrite the room-wide spend figure as a side effect of changing responder fan-out. Per-payer spend caps now have their own dedicated, payer-scoped write path - PUT/DELETE /api/chats/{chat_id}/my-spend-limit (UpdateMySpendLimitRequest below) - which is the ONLY way to set that figure. ChatService.update_runtime_policy carries the per-payer map through from existing stored state unconditionally, so an extra max_chat_spend_usd key in a stale client's request body is simply ignored (Pydantic's default extra="ignore"), not silently destructive.

That silence has a cost worth knowing about: because this body is extra="ignore" rather than extra="forbid", a caller still sending max_chat_spend_usd gets a 200 and no effect. That is exactly how the production room-UX smoke broke in TOS-2393 - it PATCHed a 0 cap here to force a blocked turn, the key was dropped, and the room ran uncapped. test_smoke_runtime_policy_matches_rest_contract (backend/tests/test_agent_config_contract_parity.py) now fails the PR that removes a field from this body while a hard-coded payload still sends it. TOS-2394 removed the legacy scalar entirely, so there is no longer any stored figure for this endpoint to carry or to wipe.

max_root_container_spend_usd is a DIFFERENT figure - the tree-wide container ceiling, not the per-chat cap - and review finding #3 caught that an earlier pass removed it here with no replacement write path anywhere, freezing every chat's ceiling at whatever it already held. It is intentionally OPTIONAL (None default) rather than carrying the always-defaulted Field(default=...) shape the fan-out fields use below: update_runtime_policy only overwrites the stored ceiling when this key was actually present in the request body (checked via body.model_fields_set, not is not None - the latter can't tell "omitted" from "explicitly set to null to clear it"), so a client that only changes fan-out settings and never mentions this field can't wipe it by omission - the same failure mode the fan-out-only design above exists to prevent for the chat-level scalar.