The originating settings view buffers the sanitised payload while pinned siblings take the persisted record #2354

Spotted while clearing review threads on PR #1562, read from ClineProvider.ts at its head 82f0a9af7.

setValues with a savedProfileName / savedProfileSettings second argument splits its writes in two sources:

• the originating view is updated from the sanitised payload: invalid display values and mode validation run first to produce sanitizedValues, apiConfiguration is stripped from the shared values for the touchesProviderKeys branch, and the originating view local state is then saved from sanitizedValues.
• the pinned sibling views are updated from the persisted record that the profile save returned, filtered by instance !== this so the originator is deliberately left alone, and a sibling handler is rebuilt only when that task really hangs under the replaced profile.

After one save, the view that made the call renders the sanitised request while the other views render what the store actually wrote. Those agree only when nothing else moved in between: a concurrent save, a profile replaced under the same name, or a normalisation the store applies that the payload did not carry.

Nothing pins which source the originating view should use. _saveViewLocalStateFromMutation is called 11 times in ClineProvider.ts (lines 1202, 3452, 3481, 3877, 3998, 4077, 4148, 4206, 5458, 5583, 5616). __tests__/ClineProvider.spec.ts mentions it 6 times, all at lines 6001-6006 and 6827-6844, and all six are instrumentation: the first spies on the prototype to fail the paired per-view write inside a shared-write rollback case, the second is a fabricated sibling double for the sibling-refresh-failure case. Neither asserts what the view that made the call has buffered afterwards, and no case calls refreshViewLocalStateForUpdatedProfile (declared at line 4065, filtering instance !== this && instance.pinnedProfileName === name at line 4067) and then reads the originator own local state.

Filed rather than fixed: switching the originating write to the persisted record is one argument at that call site, but it changes the shared-write and rollback contract of the same method, so it wants an originating-view test plus a negative control. PR #1562 already reports 2128 changed executable lines against a 500-line cap, so adding it there is not free. Filed so the choice is a decision rather than an accident.