feat(webview): per-view ack, history and profile restore writes (N5, split 5/5 of #1546) - #2237

- omit viewStates (host-minted claim tokens) from settings export
- keep a pre-launch selection when registration re-keys onto an existing stable entry
- narrow saveViewState keys to the durable per-view subset
- skip rollback when another provider wrote a newer shared value
- restore the ContextProxy cache when globalState.update rejects
- clarify that the claim is enforced by setViewStateId; launch wiring follows

…te rejects

Track a per-key write generation so a rejected write only rolls the cache back while it is still the newest write for that key; also stop tracking the generated .husky/_ hook files.

…file deletion

- prune persisted view states: never age out entries of live views
- mode switch: drop the unconditional shared-mode rollback (setValue already guards it)
- mode switch: restore the pre/post-read abort guards around mode config reads
- deleteProviderProfile: point the settings manager at the surviving profile

The generated .husky/_ files stay untracked; pre-commit/pre-push belong to main and must not be deleted by the unit.

A write pending across resetAllState() must not restore its pre-reset value when it rejects afterwards; bump the generation of every tracked key during the reset, with a test.

… overlays

- register configuration.customModes before setValues validates the mode
- roll shared values back when a multi-key ContextProxy write rejects partway
- pin a persisted profile name only with the configuration it resolves to
- skip the buffer update when a reset ran during the durable save
- guard the shared rollback with per-key write generations, not values alone
- rebuild sibling task handlers when their pinned profile settings change

- ContextProxy tracks the last persisted value per key and rolls a failed write back to it, with a both-writes-reject test
- deleteProviderProfile retries the settings-manager name update and reports an incomplete repair after posting state
- deleteProviderProfile re-pins sibling views still buffered on the deleted profile

…estore

- ContextProxy: seed the persisted-value map in initialize so a failed write on a key that
  has never been written through this proxy rolls the cache back to the value storage actually
  holds instead of an overlapping write's pending value.
- ClineProvider.loadViewState: keep the profile name and the settings it resolved to as one
  pair; a profile name this view changed while the lookup was in flight no longer inherits the
  loaded profile's configuration.
- ClineProvider.getState: read this view's restored mode from the buffer - getState() is what
  task creation and getStateToPostToWebview read, so a restored mode has to be visible there.
- ClineProvider.deleteProviderProfile: clear the settings overlay of every view re-pointed away
  from the deleted profile when the survivor's settings cannot be resolved, and rebuild the live
  task (in this view and in sibling views) that still names the deleted profile.
- ClineProvider.setValues: roll a partially applied shared write back through the
  generation-guarded helper instead of replaying every captured value.

Tests: 1 new ContextProxy case and 4 new ClineProvider cases, each red before its fix and green
after it; 43 suites / 1188 tests pass under core/webview + core/config.

…ites read back from the Memento

updateGlobalState now corrects the cache from what the Memento reports when a still-current write
rejects, which is the policy main shipped, so the per-key record of what storage last accepted has no
reader left. git grep over the whole tree found exactly three references to statePersistedCache - the
field declaration, the write in initialize() that seeded it from the loaded values, and the write on
the success branch of updateGlobalState - and none of them reads it, so all three are gone and the
success handler is back to main's `.then(release, ...)`. Behaviour is unchanged: nothing observed the
map. Our per-key write generations and getStateWriteGeneration are untouched, and the two generation
lines inside updateGlobalState are still the only difference between our method body and main's.

Changed executable lines against upstream/main e943530 (same script, same base): extension 827 ->
824 in the report below.

Gates: prettier --check exit 0; tsc --noEmit exit 0; eslint --max-warnings=0 --no-warn-ignored exit 0;
vitest core/config + core/webview = 44 files / 1,290 tests passed, the same counts as before the
removal.

…split harness

The merge e943530 left ten titles in src/core/webview/__tests__/ClineProvider.spec.ts
without survivors in our tree - all in-base, all absent on our pre-merge parent
9819b5f, none elsewhere in the tree, and every production symbol they exercise still
present. They are test-only, so they are ported here rather than answered in writing.

Ported verbatim from e943530^2 into the same describes. What our rewrite had done to
each case, by title:

Deleted outright (the distinctive fixture literals survived only inside the file-level
vi.mock factories; the assertions did not) - re-adopted here:
  validates and falls back to default mode when restored mode no longer exists
  preserves mode when it exists in custom modes  (only main's negative case remained, in
    our 'should not restore a persisted mode whose custom mode was deleted')
  preserves mode when it exists in built-in modes
  handles history items without mode property
  continues with task restoration even if mode config loading fails
  updates every zoo-gateway profile and activates only the active one  (the update-all and
    activate-only probes were gone; our 'creates a Zoo Gateway profile when none exists'
    covers neither)
  skips seeding when every zoo-gateway profile already has the current token and base URL
  re-seeds when any zoo-gateway profile has a stale or missing token
  re-seeds when any zoo-gateway profile has a stale base URL  (our describe kept only
    main's first seeding case, byte-identical)
  createTaskWithHistoryItem mode validation - the grouping describe itself

Reworded to the observable this tree ships - expected values and intent unchanged (4 of
the 10, all four listed above as deleted first):
  - the three mode cases asserted globalState.update("mode", <slug>). This branch persists
    the restored mode through the view's own pin (ClineProvider.ts:1998 saveViewState, and
    the comment above it says why a global write is wrong in parallel mode), so each case
    now asserts update("viewStates", ...) plus viewLocalState.mode === <slug> and keeps
    main's getCustomModes / getModeBySlug / log-fallback / historyItem.mode assertions
    untouched. Nothing was dropped or loosened: the same value is pinned, for this view.
  - the gateway case asserted saveConfig("Backup Zoo", objectContaining(token, baseUrl)).
    This branch refreshes every zoo-gateway profile through upsertProviderProfile so that a
    view pinned to a profile re-resolves it (ClineProvider.ts:3393-3407), so the case now
    asserts the second upsert call carrying activate:false and that saveConfig was not
    called at all. The title's 'activates only the active one' is asserted, not implied.

Harness-only edits inside the ported blocks: the readonly member swaps go through one
declared structural type (MemberSwapTarget) instead of 'as any', and mock payloads use
as never, so this file's no-explicit-any suppression count did not rise.

Verification: prettier --check clean; tsc --noEmit -p . clean; eslint --max-warnings=0
clean (0 errors) on the spec plus ClineProvider.ts, ContextProxy.ts and ContextProxy.spec
.ts; vitest run core/config core/webview --no-file-parallelism = 44 files / 1299 tests
passed (1290 before, +9 ported cases). Staged explicitly: only
src/core/webview/__tests__/ClineProvider.spec.ts (+424 -5). Measured with the same script
and base as the other heads: PACKAGE extension still 810 changed executable lines, so this
head adds 0 executable lines (spec paths never count against the 500-line gate).

…cond describe

The review thread measured true against bf7a9e9. Three cases appeared twice, identical
apart from indentation - "should merge concurrent persisted updates from separate provider
instances without lost viewStates", "should remove the buffered apiConfiguration when it is
cleared" and "should increment instance count for each new instance" each sat once inside a
describe and once as a direct child of describe("ClineProvider") - and describe("view state
persistence edge cases") appeared twice, so reports showed two groups under one name.

Deleted the three top-level copies; the in-describe copies stay byte-for-byte unchanged.
Renamed the second block to "view-local buffer: loading, setValue mutations and rollback",
which names what its four cases actually do: load the persisted mode, profile name and
resolved profile into viewLocalState; apply setValue mutations to global state and keep or
clear the buffered fields; drop the buffered apiConfiguration when it is cleared; roll back
the shared write when per-view persistence fails. The first block keeps the old title - its
eleven cases are all persisted-viewStates edge cases, which is what it says.

Survivor check before pushing: 349 test titles in the file before, 346 after; each of the
three names still appears exactly once and no title dropped to zero. Three other same-title
pairs exist ("handles case when no current task exists", "loads saved API config when
switching modes", "saves current config when switching to mode without config") and are left
alone: their bodies differ, so they are not duplicates of each other.

prettier --check, tsc --noEmit -p . and eslint --max-warnings=0 are clean, and vitest
core/webview is 34 files / 982 tests green. No production file is touched, so the scope
measure still reports the same 810 extension-package executable lines.

The review thread on the seeding suite measured true against 45795c8: every seeding case
put a single zoo-gateway profile in the store, where a first-only check, a last-only check,
an every-profile check and the shipped any-profile guard all take the same branch, and the
case titled "...stale or missing token" never left zooSessionToken unset.

Added three cases, with the production guard untouched. Two run through it.each over a store
of ["Zoo Gateway", "Other", "Zoo Gateway 2"] where "Other" is an anthropic profile: one with
the stale profile last, one with it first; each asserts handleZooCodeCallback ran with the
fresh token and that getProfile was never asked about "Other", which is what exercises the
apiProvider filter. The third gives a zoo-gateway profile with a current base URL and no
token at all, and asserts seeding still runs.

Controls, each applied to src/core/webview/ClineProvider.ts, measured, then reverted (the
file's blob is ee8203a before and after, and git checkout HEAD -- confirmed it):
zooGatewayProfiles.slice(0, 1) fails the stale-last case; .slice(-1) fails the stale-first
case; replacing the apiProvider filter with () => true fails the "Other" assertion in the
stale-last row; requiring a non-null token before comparing fails the no-token case. Every
mutation kills exactly one test and nothing else.

vitest core/webview + core/config: 44 files / 1299 tests green (1296 before this commit, plus
the three new cases). prettier --check, tsc --noEmit -p . and eslint --max-warnings=0 are
clean; scope unchanged at 810 extension-package executable lines (no production change).

…ting profile save

The activating branch refreshed sibling views inline; the non-activating branch checked only
this.pinnedProfileName, so a save that did not activate left every other live view pinned to
that profile serving its buffered copy of the old settings, and left any task following the
profile with the handler built from them. That branch is load-bearing: handleZooCodeCallback
routes non-active Zoo Gateway profile updates through it.

refreshSiblingsAfterProfileSave is ported unchanged from the n4 head (877ea0a) rather than
invented a third time: one overlay loop over the instances pinned to the saved name, then a
separate task loop. The separation is itself the second half of the fix - the inline copy on
this head nested the task rebuild under the same pinned-name check, so a task restored from
history that follows profile A inside a view pinning profile B was never rebuilt. Both save
branches now call the one helper. ClineProvider.ts 6442 -> 6456 lines.

Tests. The existing sibling case drove activate=true while its comment described the false
branch, so it is renamed to say "pinned to the activated profile" and its comment corrected.
Two cases arrive with the capability: the same save with activate=false, asserting the pinned
sibling's buffered overlay moves to the saved settings; and a sibling whose task follows the
saved profile while its view pins another, asserting the handler rebuild still happens. Both
fail against 723c363 (expected undefined to deeply equal { apiProvider: 'anthropic', ...1 };
expected "vi.fn()" to be called with arguments [ ...2 ]).

Controls (ClineProvider.ts snapshotted at ff22c45, restored by content hash after each):
drop the non-activating call -> the overlay and task cases fail, the activating case passes;
drop the activating call -> only the activating case fails; nest the task rebuild back under
the pinned-name check (the shape this head had) -> only the task case fails; delete the
helper's overlay write -> both overlay cases fail.

Gates: prettier --check clean; tsc --noEmit -p . clean; eslint --max-warnings=0 clean on both
files; vitest core/webview + core/config 44 files / 1301 tests green (1299 before, +2 cases).
Scope 810 -> 815 extension-package executable lines (types unchanged at 8).

…ck generation guard

_restoreSharedValuesAfterFailedViewWrite gates every key on the per-key write generation the
setter captured. ContextProxy counts only cached global-state writes: secrets go through
storeSecret and pass-through keys straight to the Memento, and neither advances the map, so
those keys are captured with generation 1 and still read 0 afterwards. The guard is never
satisfiable for them, which exempts exactly the keys whose value cannot be compared back
(a secret is not in getValues, a pass-through key is not cached) from the rollback of their
own failed attempt: after a failed per-view write the secret and the durable task history
stay at the value the failed attempt wrote while every other key is restored.

The filter now skips the generation clause for keys the repo's own predicates say ContextProxy
does not count - isSecretStateKey from @roo-code/types and isPassThroughStateKey from
../config/ContextProxy - and keeps it everywhere else. ClineProvider.ts 6456 -> 6464 lines.

Tests (three cases, all red before the change).
- a secret key (nanoGptApiKey) written alongside a counted key with the per-view write
failing: asserts the store moved to the new value and the cache is back to the old one;
failed with expected 'new-secret' to be 'old-secret'. storeSecret is fire-and-forget, so the
attempted value is asserted by presence, not order.
- a pass-through key (taskHistory) in the same shape: asserts the Memento was written the new
history and then the old one; received only the new write before the fix. The double delegates
to the real store, because replacing it would also silence the read-back the guard compares.
- the guard's own case: a concurrent provider re-writes the very value the attempt wrote, so
only the generation distinguishes them; asserts the newer write stands. Without the generation
clause it reads expected 'architect' to be 'code'.

Controls (ClineProvider.ts snapshotted at 8a5977a, restored by content hash after each):
drop the exemption (the previous guard) -> the secret and pass-through cases fail and the
other three pass; delete the generation clause -> only the same-value case fails, so the guard
is still load-bearing for counted keys; delete only the secret arm -> only the secret case
fails; delete only the pass-through arm -> only the pass-through case fails.

Gates: prettier --check clean; tsc --noEmit -p . clean; eslint --max-warnings=0 clean on both
files with no suppression count changed; vitest core/webview + core/config 44 files / 1304
tests green (1301 before, +3 cases). Scope 815 -> 818 extension executable lines (types 8).

…g rows

CodeRabbit's point measured rather than argued. The two it.each rows share the store order
["Zoo Gateway", "Other", "Zoo Gateway 2"], so only one of them can ever fail
expect(...).not.toContain("Other"): with the stale profile first the every-profile loop breaks
before it reaches the non-gateway profile, so that row cannot observe the filter at all.

Mutants run against 27a2836, production untouched (blob 8a5977a, restored by content hash
after each):
- drop the provider filter in ensureZooGatewayProfileSeeded: fixture as shipped -> 1 of the 2
rows fails (expected [ 'Zoo Gateway', 'Other', ...1 ] to not include 'Other'); with "Other"
leading the store -> both rows fail. The assertion goes from one-row to two-row coverage.
- check only the first gateway profile (the bug the comment describes): 1 row fails on the
handleZooCodeCallback assertion, before and after the reorder, so the reorder does not weaken
the detection this fixture pair exists for.
- no mutant: 397 tests in the file pass.

Test-only: the store order of the two rows moves and the comment records why "Other" leads.
No assertion was added, weakened or deleted - nothing deleted here, duplicate or coverage - so
the number a maintainer needs is 0 deleted-duplicate, 0 deleted-coverage, 1 assertion made
load-bearing in a second row. Gates: prettier --check, tsc --noEmit -p . and eslint
--max-warnings=0 clean; vitest core/webview + core.config suites 44 files / 1304 tests green.

…when it fails

This branch had no write guard at all. There was no reset flag, storeSecret() had nothing telling it a
reset was in progress, and resetAllState() cleared the two caches, deleted every global-state and secret
key in a single Promise.all and reinitialized - the success path being the only path. A save issued while
a reset was still inside its deletes could therefore land after the deletes and put back a value the user
had just erased. This commit introduces the guard, so on this branch the refusal is new behaviour rather
than a repair of an existing one, and it should be read as scope rather than as a bug fix to code that
already refused writes.

What lands: a resetting field, a rejection at the top of storeSecret() carrying the key in failed so a
caller can tell a refused save from a committed one, resetting raised as the first statement of
resetAllState() and lowered in a finally wrapping the whole body. The body itself is untouched: this
lineage has neither a pending-write barrier nor write-owner clears, and importing them from Zoo-Code-Org#2235 would
have imported a different unit's design instead of answering this unit's defect. initialize() performs no
writes, so the refusal cannot make a reset wait on itself.

Two cases, because the guard has two halves and the refusal is the new observable here, so it is tested on
its own rather than as a phase of the leak case:
- refuses a secret write issued while a reset is still inside its delete pass
- accepts a secret write again after a reset whose delete pass rejected
Assertions read captured call arguments (mockSecrets.store.mock.calls filtered on the key) and the cache
and storage read-backs, not toHaveBeenCalledWith: that matcher compares the way toEqual does and drops
undefined-valued keys, so a loose matcher would pass on a tree where nothing is refused at all.

Controls, measured in five steps rather than described. Baseline at e398b67: Test Files 10 passed
(10), Tests 314 passed (314). Refusal case alone with production untouched: 1 failed | 314 passed (315),
AssertionError: expected undefined to be an instance of SettingsWriteError - with no refusal the mid-reset
save simply succeeds. Guard and refusal with the flag lowered only on the success path: 10 passed (10),
315 passed (315). Leak case added against exactly that shape, which is the negative control for the
finally: 1 failed of 316 with the production consequence in the message - promise rejected
"SettingsWriteError: Could not store apiKey: secret writes are refused while state is being reset"
instead of resolving. With the try/finally: Test Files 10 passed (10), Tests 316 passed (316), identical
before and after prettier.

gates: tsc -p . --noEmit exit 0, eslint --max-warnings=0 --no-warn-ignored on both files exit 0, and the
recorded suppression counts for the two touched files stand at 1 and 5 across a --prune-suppressions run;
prettier --check exits 0 on the working copies and 0 on the HEAD copies fed through the same invocation,
so a format failure here would be this commit's. src/eslint-suppressions.json untouched.

Size posture, with the pair printed: scripts/stryker-diff.mjs ci --base
e943530 (main's tip, this PR's recorded base) --head
e398b67 (this commit's parent) exits 1 and puts the
extension bucket at 566 changed executable lines against MAX_CHANGED_LINES 500. This commit
adds 29 added / 14 deleted in src/core/config/ContextProxy.ts plus 69 lines in its spec, and the spec half
is excluded from the bucket by the /__tests__/ segment at scripts/stryker-diff.mjs:85. Stryker itself could
not start locally for either package (spawnSync node_modules\.bin\stryker ENOENT), so no mutants were
scored here and only the size line is a real measurement; it belongs in the PR body or the maintainers'
queue rather than being argued in a commit on a branch declared final.

This ports the answer measured on vps2/n2-viewstates-durability and vps2/n4-values-reset so the three
sibling units do not ship three different answers to one defect. It closes no review row on this PR of
itself.

resetState cleared only this view's view-local buffer, but the shared store it just cleared is what
every view reads from - and getState() reads the view-local buffer first. A sibling view therefore kept
serving its pre-reset mode (and its stale settings) after the reset. Every live instance is cleared now.

ClineProvider.spec 364 passed, tsc --noEmit 0 errors, eslint --max-warnings=0 exit 0.

…posing in the mock

Two test-quality findings from review: the new provider-settings doubles used `(provider as any)` plus
`as any`, when the file already has a named view for that (MemberSwapTarget), and the sticky-mode view
mock fired onDidDispose's callback during registration, so the view was disposed before
resolveWebviewView finished and the stale check took the sidebar branch. The mock now only returns a
disposable; tests that need a disposal fire it themselves.

ClineProvider.spec 397 + sticky-mode 27 passed, tsc --noEmit 0 errors, eslint --max-warnings=0 exit 0
(suppressions pruned, total down, never up).

Pins three behaviours the CodeRabbit review asked about, all of them test-only.

- getValues() exposes the restored profile name and the configuration it resolved
to, while getState() and the state posted to the webview still resolve the shared
profile. That split is what the review asks to close; both sides are pinned here so
the eventual fix flips a visible assertion instead of passing unnoticed.
- createTask registers the custom modes of a configuration before it calls
setValues(), so a slug passed in the same call survives validation. The resolver
fixture now answers from the custom-mode list the provider just read instead of
accepting every slug, which is what pins the ordering.
- handleZooCodeCallback: the existing case rejects the state read and never reaches
the write, so its title now says so, and a second case drives saveConfig rejecting
inside persistProviderProfile, which upsertProviderProfile swallows, logs and
reports to the user while the state is still posted.

…nd hand readers the profile this view pinned

getConfiguration() filtered only the top level of the object it hands out. The secret
storage keys are keys of ProviderSettings (SECRET_STATE_KEYS at
packages/types/src/global-settings.ts:362-398, SecretState at :410), and
ClineProvider.getValues() merges the view buffer over the shared values at
src/core/webview/ClineProvider.ts:4512, so a restored or edited profile carried its
key through the public API for any extension holding it. The nested configuration is
now filtered with the same predicate the top level uses, and the merged object is
returned untouched when there is nothing to strip, so readers that compare identity
are not disturbed. Review row 4509495968.

getState() resolved mode from the view buffer and the profile from shared state: the
only viewLocalState reference in its body was the mode line, while apiConfiguration
came from getProviderSettings() and currentApiConfigName from stateValues. An idle
second view therefore displayed - and started tasks with - the profile the last
committing view activated. Both fields now resolve the pinned pair first and fall
back to the shared pair when this view holds no pin. Review row 4509495951, second
finding.

Legs on this tree: prettier --check . exits 0 ("All matched files use Prettier code
style!"); eslint --prune-suppressions --max-warnings=0 over the four touched files
exits 0 and left src/eslint-suppressions.json canonical-identical (265 entries,
26,403 bytes) after re-serialising it twice, so both re-serialisations were reverted
and no count moved upward; pnpm --dir src run check-types exits 0 with zero error
rows. vitest run extension/__tests__/api-configuration.spec.ts is 11/11 passing, and
vitest run ClineProvider is 643/643 passing across 13 files.

Negative controls, one fix removed at a time, so the two fixes are shown to be
load-bearing rather than present: with src/extension/api.ts back at its previous
body, "strips provider secrets nested inside the configuration it hands out" fails
at src/extension/__tests__/api-configuration.spec.ts:87 on
expect(configuration.apiConfiguration).toEqual(...) (1 failed, 10 passed); with
src/core/webview/ClineProvider.ts back at its previous body, "keeps the restored
profile visible to public readers when the shared store names another profile" fails
at src/core/webview/__tests__/ClineProvider.spec.ts:6964 on
expect(state.currentApiConfigName).toBe("my-profile") (1 failed, 403 passed). The
pins at ClineProvider.spec.ts:6962-6970 are deliberately flipped from the shared
pair to the pinned pair, and the reviewer ask on row 4509495951 is what justifies
the flip. No changeset, no changelog entry.

…ttings

getState returns this view's buffered apiConfiguration in place of the store's
provider settings whenever the buffer holds one, so a mutation that moved the
shared settings after the pin was written stayed invisible to every consumer.
Layer the pin over the settings the store holds now instead of replacing them.

Measured locally on a mocked footing at the merge base with this file and the
three files it needs: 45 passing / 29 failing becomes 48 passing / 26 failing;
three Roo Code Subtasks failures are taken and none is added. The mocked row
is still red: 21 head-side failures remain beyond the five that also fail at
the merge base, and the hosted row for this commit has not been read.

A cancelTask rehydrate inside a suite writes the durable per-view profile pin and the view-local buffer, and the next suite then resolves the provider that pin points at instead of the one its own setup configured. RooCodeAPI exposes no door onto either one, so the mocked harness reaches the provider object the exports hand back and clears both after every test.

…tes where the rollback guard reads

Delete-profile repair: install the surviving profile's settings before re-pointing a view that was pinned to the deleted profile, so a settings write that rejects can no longer leave the shared store naming the survivor while it still carries the deleted profile's settings. A pinned view is still re-pointed when nothing resolved to install.

ContextProxy: advance the per-key write generation in storeSecret the way updateGlobalState does, and widen the map's key type across both stores, so ClineProvider#_restoreSharedValuesAfterFailedViewWrite can tell its own secret write from a newer write of the same secret value. Dropped the secret half of that guard's exemption - pass-through keys stay exempt - and the now-unused isSecretStateKey import.

api: drop the per-view state record from getConfiguration() so an extension that holds the API configuration is not handed every view's buffer.

Tests: the delete-profile half-repair, the per-key generation a rollback reads from a secret write, the guard against a newer same-valued secret write, and the record kept out of the configuration read. The existing secret-rollback case is renamed to say what it now proves.

Rebased onto f2b4d1c. Four hunks needed hand reconciliation and are
nameable: the write-generation counter had to go back into updateGlobalState beside the trunk's
write-owner machinery (the provider rollback reads it); the fire-and-forget post and the view-resolve
html block came through twice and one copy of each was removed, the surviving post carrying the
diagnostics records and the dropped-message log on both paths; the view-dispose registration came
through twice and the copy kept is the one that clears the panel; and the mode-validation describe
existed once on each side, so the trunk's copy was dropped and its two per-provider mode-to-profile
mapping lines were folded into the copy kept, which asserts the view's own pin instead of the shared
mode write the pre-rebase trunk asserted.

The suppression registry lands two lines below the trunk tip's: the merged file carried 60 entries
that neither parent had (left from the mid-replay state an entry-wise merge read) and two counts above
what the merged tree contains. Measured with --prune-suppressions against a scratch copy of the
registry, the shared file never pruned by the tool, the registry is the trunk tip's text with
core/webview/__tests__/ClineProvider.spec.ts at 151 where the trunk side recorded 195 and
core/webview/__tests__/ClineProvider.sticky-mode.spec.ts at 26 where it recorded 27 - both files this
branch rewrites, both counts down, none up. eslint over the whole src project with no prune switch now
exits 0 with no output.