fix(view): refuse worktree-cwd mutations when the route isn't ready, instead of silently editing the wrong checkout

[timkjr]

Summary

Fixes a silent wrong-checkout write: when an MCP session's working directory is anchored inside a linked git worktree, and that worktree's view route can't yet serve (not fully published), a mutating tool call (edit_file, write_file, edit_symbol, batch_edit, and the refactor facade's rename_symbol/move_symbol/safe_delete_symbol/inline_symbol/apply_code_action/fix_all_in_file) previously degraded silently to the base corpus. For a file that exists in both the worktree and the main checkout, that meant the edit landed in the main checkout instead of the worktree — while the caller's context (cwd) said it was editing the worktree.

• viewForSessionCWD (internal/mcp/view_request.go) now refuses loudly (view_building) when the checkout is ready+automatic but its route can't yet serve and the request is a mutation (detected via the WithAuthorizedToolCall context marker + facades.mutatesSource). A read still degrades softly to base, but now carries a rider naming which checkout was actually wanted, so the degradation is visible rather than silent.
• A second, independent gate (refuseRoutedViewMutation) catches the case where no marker was present (so the first gate couldn't tell it was a mutation): it keys off the request's own tool name instead, and refuses an inexact/fallback view for any mutating tool — so even a marker-less call fails safely to a view_read_only refusal rather than writing base.

Test plan

• TestCWDBindingRouteNotReadyMutationsRefuseLoudly / ...ReadFileIsLabeled / ...ReadsFallBackWithRider — pre-existing coverage for edit_file and reads (unchanged behavior, retained as regression pins)
• TestCWDBindingRouteNotReadySoleRepoMutationRefusesLoudly — same refusal holds in a single-tracked-repo topology (bare/unprefixed paths), not just the two-repo fixture
• TestCWDBindingRouteNotReadyBatchEditRefusesLoudly — batch_edit (a different code path than edit_file, via handleAtomicBatchEdit) refuses identically
• TestCWDBindingRouteNotReadyWriteAndEditSymbolRefuseLoudly — write_file and edit_symbol parity with edit_file
• TestCWDBindingRouteNotReadyRefactorFacadeRefusesLoudly — extends coverage to the refactor facade's six tools (apply_code_action, safe_delete_symbol, fix_all_in_file, inline_symbol, move_symbol, rename_symbol), which share the mutation gate with the edit facade but had no prior regression coverage
• TestCWDBindingRouteNotReadyMissingMarkerFailsOpenToReadOnly — a marker-less mutation still gets caught by the second gate (view_read_only), not a silent write
• go build ./... and go vet ./... clean
• go test ./internal/mcp/... (full package, not just the new tests) — clean, twice
• go test ./... (repo-wide, excluding -race per the known internal/mcp/store_sqlite/indexer timeout) — clean; one unrelated pre-existing flake in internal/indexer under full-parallel load (TestSpecLaunch_4_5_CrossWorkspaceHappyPath, times out only under full-suite parallelism, passes in isolation in <1s, zero overlap with this diff) — not touched by this change
• Live-verified against a running daemon (not just the test fixture): rebuilt the binary from this branch, restarted the daemon, ran a real edit_file through a fresh worktree-anchored session — the edit landed only in the worktree copy, main checkout untouched

[timkjr]

I had this fix deployed in my local server, but found the exact bug this PR targets reproduced live today in an unrelated repo — a separate, narrower gap in the same incident family, not a regression in what's already here.

Root cause: worktreeRootedPath (internal/mcp/tools_fileops.go) short-circuited on the first os.Stat hit against the resolved (main) checkout and returned immediately — it never checked whether a linked worktree also carried the file. So an unrouted, unprefixed edit whose target existed in both checkouts silently landed in main instead of refusing or asking, even with this PR's CWD-gate fix in place (that gate only fires when the session's cwd is bound to the worktree; an unprefixed path resolved via the sole-repo/anchor fallback never goes through it).

Added in 0679bea2: refuse with a clear error when an inferred path anchor (not an explicit repo-prefixed one) resolves ambiguously between main and a worktree, plus a regression test pinning it. Scoped narrowly — an explicitly repo-prefixed path keeps the existing behavior, so it doesn't regress the main-checkout-prefix contract this PR already tests for.

[zzet]

Request changes: the new ambiguity guard still falls back to the main checkout when more than one linked worktree contains the inferred target, preserving the wrong-checkout mutation this PR is intended to prevent.

[zzet]

[P1] Refuse ambiguity between multiple linked worktrees

When a second linked worktree contains the inferred file, this branch returns the original main-checkout path with no error before the new ambiguity check can run. An unrouted mutation can therefore still edit—or create—the main-checkout file when two worktrees contain the target. When refuseAmbiguous is true, return errPathAmbiguousCheckout on the second distinct match, and add tests for main + two worktrees and for two worktrees with no main file.

[timkjr]

Thanks for catching this. You're right: the second-worktree branch returned abs before the main-vs-worktree refusal could run. Fixed in b2302cb.

Fix: with refuseAmbiguous set, worktreeRootedPath now returns errPathAmbiguousCheckout on the second distinct worktree match. An explicit selection (refuseAmbiguous=false, i.e. a repo-prefixed path) still keeps the resolved path, so the main-checkout-prefix contract is unchanged. I updated the doc comment to match.

Tests:

• TestWorktreeRootedPath_MultipleWorktrees covers the two cases you asked for, main + two worktrees and two worktrees with no main file, plus the explicit-selection pass-through.
• TestEditTools_UnprefixedPathAmbiguousAcrossTwoWorktrees drives edit_file and write_file end to end against a real MultiIndexer tracking main plus two worktrees. It asserts the refusal surfaces as the tool error and that no checkout's bytes change, and no file is created in main.

Scope of the gap: writing the end-to-end test showed that in that topology the tool path was already refusing before this fix. anchorUnprefixedExisting counted the file in several tracked repos and returned "names a file in multiple tracked repos", so no wrong-checkout write went through. The gap was in the helper: called directly with refuseAmbiguous=true, it returned the main-checkout path. The sole-tracked-repo branch of resolveFilePath can't see linked worktrees in the first place, because a tracked worktree adds its own prefix. With this change the helper enforces the refusal itself instead of relying on the caller's match count, and the end-to-end test now asserts the checkout-ambiguity error specifically.

Also worth noting:

• Read-only callers of resolveFilePath now get errPathAmbiguousCheckout for an unprefixed path present in two or more worktrees, matching the main-plus-one-worktree refusal from 0679bea.
• I added the blank // line gofmt wants before the refuseAmbiguous paragraph in the doc comment. 0679bea had left that paragraph unformatted.

Verified locally: go test -race ./internal/mcp/... and golangci-lint v2.13.1 on ./internal/mcp/... are both clean.