Each delta operation's declared size is validated against the
size still remaining in the target buffer, not the total target
size. The previous check against the total accepted a sequence of
operations whose cumulative output would exceed the declared
target, leaving the unsigned remaining counter unable to reach
zero and the loop free to keep writing past the declared target
until the delta payload was consumed.

Three sibling code paths shared the flaw and are updated together:
`patchDelta` (used by `PatchDelta` and `ApplyDelta`),
`ReaderFromDelta`, and `patchDeltaWriter` (used by the packfile
parser).

The loop structure is rewritten as `for remainingTargetSz > 0`
so the invariant is explicit, and a post-loop check rejects
deltas that leave bytes unconsumed -- matching the `data != top`
sanity check in `patch-delta.c`[1]. Empty-target deltas
(header-only, no operations) are now accepted, also matching
upstream.

Several incidental defects on the same call paths are fixed:
`patchDelta`'s copy-from-src failure used `break`, which only
exited the switch and let the loop keep consuming delta bytes;
`patchDeltaWriter` returned `(0, ZeroHash, nil)` on invalid input,
silently reporting success; and `ReaderFromDelta`'s copy-from-src
failure closed the writer without an error, silently truncating
the consumer stream. Each now propagates `ErrInvalidDelta` (or
`ErrDeltaCmd`) consistently.

`packfile.getMemoryObject` was re-inflating delta payloads into
the buffer the scanner had already populated, appending a
duplicate copy that previously went unnoticed because the loop
silently ignored anything past the target. The fix matches the
cached-content pattern already used in `Scanner.WriteObject`.

[1]: https://github.com/git/git/blob/c2c5f6b1e479f2c38e0e01345350620944e3527f/patch-delta.c

Assisted-by: Claude Opus 4.7
Signed-off-by: Hidde Beydals <[email protected]>