Validate mutable session settings against allowed transitions

Validate mutable session settings against their reserved allowlist, while checking session identity and authorization scope as immutable. Comparing every runtime field to the initial allocation can make an allowed change succeed and then break the next status read, message, reconnect, or stop. Keep exact initial-setting validation at startup; test change → follow-up → reconnect through the actual API guard, including rejection of settings outside the allowlist and scope drift.

Evidence/example — 2026-09-11: an author-run synthetic model-A/model-B gateway regression and browser reproduction showed a switched-model response succeed, followed by a request rejected before model dispatch because runtime model B differed from initial model A despite both being allowed. Separating startup equality from runtime membership made the follow-up pass while rejection cases stayed enforced. Provenance: source inspection, failing-then-passing gateway/HTTP tests, and observed browser behavior; private session details omitted.

Limit: this mechanism explains rejection before dispatch. It does not establish why a completed provider response might later be lost during streaming or UI restoration.