GitPatchBuilder doesn't pin context lines or rename detection, so host diff.context=0 yields patches Apply can't stage #121

What's wrong

GitPatchBuilder pins host settings that would otherwise change the shape of the patch: prefixes, color, ext-diff, textconv and suppressBlankEmpty. That follows the repo's stated policy. Two settings are not pinned (GitIntegration/Builders/GitPatchBuilder.cs:~180-188).

Context lines

-U is only passed when WithContext(n) is called. WithContext(0) is deliberately refused, because a zero-context hunk needs --unidiff-zero to apply. The default path, where WithContext is never called, instead inherits diff.context from git config.

In a repository with diff.context=0, changing line 25 of a 50-line file produces @@ -25 +25 @@. Feeding that patch to Apply(...).ToIndex() fails with error: patch failed: f.txt:25. This is the failure the WithContext remarks say the builder prevents, and it is reported against the index rather than the config setting.

Rename and copy detection

--find-renames is only added when DetectRenames() is called. Nothing turns renames off otherwise, and git enables them by default:

• Staged renames come back as Renamed even without DetectRenames().
• With diff.renames=copies, git emits copy from / copy to headers. The parser ignores those, so a new copied file is reported as Kind = Modified with OriginalPath = null.

Suggested fix

• Always emit -U{_contextLines ?? 3}.
• Emit --no-renames unless DetectRenames() was called.
• Optionally, recognise copy from / copy to in GitPatchParser.ApplyHeaderLine.
• Add a builder test asserting the argument list contains -U3 and --no-renames by default. Add an integration test with diff.context=0 set in the fixture repository, asserting the patch round-trips through Apply(...).ToIndex().