fix(core): describe the real cause of the edit stale-content failure

[rareboe]

Issue for this PR

Closes #48707

Type of change

• Bug fix
• New feature
• Refactor / code improvement
• Documentation

What does this PR do?

edit reported File changed after permission approval. Read it again before editing. for every stale-content failure, which names a cause the error has no knowledge of.

FileMutation.StaleContentError is raised in writeIfUnchanged purely from a byte comparison under the per-path lock:

const current = yield* fs.readFile(input.target.canonical)
if (!sameBytes(current, input.expected)) {
  return yield* new StaleContentError({ path: input.target.canonical })
}

It carries only a path, and fires whenever anything writes the file inside the edit's read → write window — another session, another process, the user's editor. The permission wording is introduced entirely by the mapping in tool/edit.ts, which is the only place that maps this error.

The repo's own regression test makes the mismatch plain. rejects an in-place content change after matching but before conditional commit simulates a plain concurrent write with no permission flow involved, and asserted the permission wording anyway.

So this renames the condition to what actually happened and keeps the same remedy: File changed since it was read. Read it again before editing.

Behaviour is unchanged — same error, same failure path, same instruction to re-read. Only the sentence is different.

I checked apply-patch for the same problem; it does not map StaleContentError, so edit.ts was the only occurrence.

How did you verify your code works?

The string is pinned by the existing concurrent-write test, so updating it is what proves the change is scoped to this one message and nothing else reads it:

$ bun test test/tool-edit.test.ts test/tool-apply-patch.test.ts test/file-mutation.test.ts
 32 pass, 0 fail

$ bun typecheck        # packages/core
(clean)

Screenshots / recordings

Not a UI change.

Checklist

• I have tested my changes locally
• I have not included unrelated changes in this PR

[github-actions]

The following comment was made by an LLM, it may be inaccurate:

Based on my search results, I found one potentially related PR that addresses a similar issue:

Related PR:

• fix(opencode): reject stale patch sources after approval #47956 - fix(opencode): reject stale patch sources after approval

This PR also deals with stale content/state handling in the context of approval workflows and patching operations, which is related to the stale content error handling being fixed in PR #48904.

However, this is addressing a different aspect (stale patch sources vs. stale file content in edits), so it's not a direct duplicate.

Conclusion: No direct duplicate PRs found. PR #48904 appears to be addressing a specific bug fix for improving error messaging around stale content failures in the edit tool.