fix(windows): block reserved names in tools

[applerom]

Summary

• reject reserved Windows device basenames in write, edit, and patch flows
• block literal reserved-name redirects like ">NUL" when the bash tool runs in a POSIX shell on Windows
• add Windows-focused regression tests for reserved names and literal redirect targets

Why

On native Windows, OpenCode can run the bash tool through Git Bash or another POSIX shell. In that setup, cmd-style redirects like >NUL can create a literal reserved-name artifact instead of discarding output. File-writing tools also accepted reserved Windows basenames directly, which made the issue harder to recover from once it appeared.

This PR keeps the fix intentionally narrow:

• it blocks reserved basenames in file-writing and patch flows
• it blocks literal reserved redirect targets in the bash tool on Windows POSIX shells
• it does not attempt to evaluate full dynamic shell expansion semantics

Validation

• bun test test/tool/bash.test.ts test/tool/apply_patch.test.ts test/tool/edit.test.ts test/tool/write.test.ts
• bun test test/util/filesystem.test.ts --test-name-pattern \"Windows reserved names\"

Notes

• This is aimed at native Windows execution, especially the Git Bash path selected by the current shell fallback logic.
• Dynamic shell-evaluated redirect targets are intentionally left out of scope for this minimal fix.

[github-actions]

Thanks for your contribution!

This PR doesn't have a linked issue. All PRs must reference an existing issue.

Please:

1. Open an issue describing the bug/feature (if one doesn't exist)
2. Add Fixes #<number> or Closes #<number> to this PR description

See CONTRIBUTING.md for details.

[github-actions]

This PR doesn't fully meet our contributing guidelines and PR template.

What needs to be fixed:

• PR description is missing required template sections. Please use the PR template.

Please edit this PR description to address the above within 2 hours, or it will be automatically closed.

If you believe this was flagged incorrectly, please let a maintainer know.

[github-actions]

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

Based on my search, I found potentially related PRs that addressed similar Windows reserved names issues in the past:

Related PRs:

1. fix: prevent Windows reserved device names from being added to directory checks and simplify bash description parameter #11605 - "fix: prevent Windows reserved device names from being added to directory checks and simplify bash description parameter"

   • fix: prevent Windows reserved device names from being added to directory checks and simplify bash description parameter #11605
   • This is directly related as it previously handled Windows reserved device name prevention

2. fix: prevent undeletable nul file on Windows #13406 - "fix: prevent undeletable nul file on Windows"

   • fix: prevent undeletable nul file on Windows #13406
   • Related to the same NUL file issue that PR fix(windows): block reserved names in tools #17998 is addressing

3. fix: Windows CLI and deep link issues (#11657, #11666, #11674) #11724 - "fix: Windows CLI and deep link issues (Windows: opencode CLI hangs at startup when running internal npm list / npm config get registry #11657, [Windows] Opening with deep link duplicates projects #11666, [BUG]: (app): Clicking on overflowed tab on the right in the file view/review section does not scroll it into view #11674)"

   • fix: Windows CLI and deep link issues (#11657, #11666, #11674) #11724
   • Contains Windows-related fixes that may overlap with reserved name handling

These appear to be historical fixes rather than active duplicates. PR #17998 seems to be a more comprehensive fix that blocks reserved names across write, edit, and patch flows while also handling literal redirect targets. These older PRs addressed specific instances of the problem but didn't have the complete solution PR #17998 provides.

[github-actions]

This pull request has been automatically closed because it was not updated to meet our contributing guidelines within the 2-hour window.

Feel free to open a new pull request that follows our guidelines.