Replace GNU patch with git apply for atomic diff application

[hiroshinishio]

Summary

• Migrated apply_patch.py from GNU patch to git apply - git apply is atomic (all-or-nothing), doesn't create .rej files, and is stricter about context matching (no --fuzz)
• Added PatchResult dataclass to replace ambiguous (str, str) tuple returns
• Created write_local_file utility to pair with existing read_local_file
• Renamed delete_file_by_sha to delete_remote_file and separated local/remote deletion concerns - delete_remote_file is now a pure GitHub API call, delete_file handles both remote and local
• apply_diff_to_file now handles deletion diffs end-to-end instead of rejecting them
• Removed patch from Dockerfile since it's no longer needed

Test plan

• 54 tests pass including 8 new test_apply_patch.py tests and 4 new test_write_local_file.py tests
• pylint 10.0/10, pyright 0 errors, flake8 clean
• Verify diff application works on real PRs in staging

Social Media Post (GitAuto)

GNU patch has a --fuzz option that silently applies diffs to the wrong location. We were using it. git apply is stricter - it either applies cleanly or fails entirely. No .rej files, no partial edits, no silent misapplication. Switched our diff engine to git apply for more predictable code changes.

Social Media Post (Wes)

Replaced our diff engine from GNU patch to git apply today. patch --fuzz=3 could silently match lines in the wrong place and partially apply changes. git apply is atomic - clean apply or full failure. Also cleaned up a bunch of file deletion logic that had responsibilities split across three functions. Sometimes the best refactor is just making names match what the code actually does.