file_ops: Use tmp file for original linting

[li-boxuan]

Short description of the problem this fixes or functionality that this introduces. This may be used for the CHANGELOG

Fix a potential issue that might lead to file corruption when edit linting is enabled

---

Give a summary of what the PR does, explaining any non-trivial design decisions

#3124 introduces a feature for editing: running linter twice before and after the change and only extract new errors introduced by the agent. This has some potential issues and I am working on #3649 to address them, but I feel like I am not gonna finish it in the next few days, and that PR has become harder and harder to review, thus this PR, which only focuses on a small improvement.

So what's the issue? When we run linters on the original file before our edits, we need to copy the original file and use a temporary file to lint, because linting may have side-effect (e.g. modifying the file in-place). I used the word "may" because:

1. Flake8 has no side-effect, so not a problem as of now.
2. We don't enforce this or document this "no side-effect" as a requirement for linter implementation, so side-effect is allowed.

Regardless, the "after-edit-linting" uses the same approach: backup the file before linting to avoid data corruption. We should keep our "before-edit-linting" consistent.

Why no new unittest that reproduces the issue? Well, as I have mentioned earlier, flake8 has no side-effect, so technically it's not a bug but a flaw. Therefore, there's no way to write a test that reproduces the issue.

[tobitege]

Great idea! lgtm

[tofarr]

Are there any linters that rely on relative paths between files that may be disrupted by this change?

[li-boxuan]

Are there any linters that rely on relative paths between files that may be disrupted by this change?

No, not that I am aware of, and it wouldn't make sense for single-file linters (our linter interface doesn't allow multi-file linting - even if it does, I am not aware of any linter that leverage relationships between files' relative paths).

Borderline is this PR only changes the "pre-edit-linting" behavior, meaning that it's okay to miss potential linting errors (in other words, false negatives are acceptable).