fix(file-tools): check remote binary overwrites on the execution target, not the controller

[kshitijk4poor]

On a remote terminal backend, write_file / patch no longer overwrite an existing binary file that only exists on the remote side. The existing-binary guard now checks the filesystem where the write actually runs, not the controller's disk. Fixes #122662. This salvages #123293 by @JoaoMarcos44, with @Liuzikaii (#122663, the first fix and the issue report) credited as co-author.

Why

• The guard that refuses to overwrite an existing .sqlite / .pdf / other binary target (_check_binary_document_write) ran Path(...).is_file() on the controller.
• write_file, patch and V4A run on the task's backend (Docker, SSH, Modal, Vercel sandbox, ...). A file that exists only there looked "new", so its bytes were replaced and the tool reported verified: true.
• Live-reproduced on main for both a Docker and a Vercel-sandbox environment.

Changes

• Probe the execution target (@JoaoMarcos44, fix(file-tools): decide binary overwrite checks on the execution target filesystem #123293). A new _target_regular_file_state() asks the task's own file_ops whether a regular file exists at the path the write will use. It returns exists, absent or unavailable.
  • Host-backed environments keep the old Path.is_file behaviour.
  • Locality comes from the live file_ops object, not from the env-type label or class name. fix(file-tools): probe remote targets before binary overwrites #122663 used the label, which still clobbered an environment class with no name hint (e.g. a Vercel sandbox configured as "local").
• Fail closed. If the backend can't be probed (starting, unreachable, removed), the write is refused with a message saying the file was not modified. A probe where [ -f ] succeeded but the size was unparseable counts as existing.
• New files are still allowed. Creating a new binary-extension file on the remote backend works as before.

Behaviour notes

• A binary-extension write may now start the task's sandbox a little earlier: the guard has to reach the target filesystem before later guards (approval, mirror) run. This affects cost and latency only; the sandbox would be created on the next call anyway.
• When a probe's output is polluted by shell noise, the refusal can say "existing binary file" for what is really a new file. It still refuses, as before; only the wording is off.

Validation

• tests/tools/test_remote_binary_write_guard.py: 2 test functions, 7 cases, all pass on the rebased head.
  • An existing remote-only binary is refused and left byte-identical through write_file, patch and V4A, including an environment class with no name hint.
  • A new remote binary is created.
  • An unreachable or erroring transport fails closed.
• With the guard changed to treat missing as existing (file copy, restored after), 6 of the 7 cases fail.
• tests/tools/test_file_tools.py passes too (48 passed, 2 skipped together).
• Probe (isolated HOME): an existing remote .sqlite is refused and intact, a new remote file is created, and both host cases behave as on main.

Not included

• _stale_overwrite_blocker still checks the host (Path(resolved).exists()), so on remote backends a remote-only text file with no read baseline passes the stale-overwrite guard. Same bug class, but a different guard; it's left for a follow-up.

• Absence isn't enforced at write time (andrexibiza's P2 on fix(file-tools): decide binary overwrite checks on the execution target filesystem #123293). The guard's "absent" answer is a snapshot taken before the write. If another backend process creates the file between the probe and the write, the write can still replace it. This race predates this PR, and closing it needs a backend-enforced create-if-absent write, so it's left for a follow-up.

Credit

@JoaoMarcos44's commit from #123293 is kept with authorship. @Liuzikaii submitted the first fix (#122663) and filed #122662, and is credited with a Co-authored-by trailer.