The settings 'Applies to' store uses null = 'follow the active profile',
but the API helpers (profileScoped/capabilityScoped) use null = 'target
the primary/default backend'. Every page that passed the raw override to
a request silently read/wrote the primary profile whenever no override
was set — writes landed on the right profile via other paths while reads
repainted primary's values, so profile model changes appeared to revert
(#90549 class).
Close the class at the seam instead of per call site:
- store/settings-scope: new $settingsRequestProfile computed — the
request-shaped scope (string | undefined, never null). Documented as
THE value to hand to API helpers.
- config-settings, keys-settings, messaging: consume the request-shaped
computed; ModelSettings/MemoryConnect/ProviderConfigPanel/
useEnvCredentials props narrowed to string | undefined so a
primary-targeting null can no longer be plumbed through.
- keys-settings site was a live third instance: getEnvVars(null) read
primary's env store on non-default profiles.
Regression tests: store computed shape, ModelSettings unscoped+scoped
reads, KeysSettings unscoped fetch (all fail against the old behavior;
sabotage-verified).
Teknium
c942cd9ea1