Replaying: rebuilding branches from patch files
===============================================

The FORMAT document describes what the files *are*;
this one describes how a tool turns them back into git commits, exactly.
Any implementation following these steps reproduces the stored branch SHA-exact.

For each patch name in series order, maintaining a map from reference to replayed SHA
(seeded with `BASE` -> the STACK's base):

1. Parse the patch file.  Resolve each `parents` reference through the map;
   an unknown reference is an error (series order guarantees parents were replayed first).
2. Read the first parent's tree into a scratch index (no worktree is required, ever).
3. If the diff section is non-empty, apply it to that index
   (`git apply --cached --binary --whitespace=nowarn`; the explicit whitespace flag
   keeps the subject repo's own `apply.whitespace` from rewriting or refusing recorded bytes).
   An apply failure is an error: the recorded base is the only supported target.
4. Write the resulting tree.
5. Reassemble the raw commit object: `tree` line, one `parent` line per resolved parent,
   then the stored header block verbatim, a blank line, and the message bytes
   (dropping the final newline if the `message-no-final-newline` directive was declared).
   Hash and store it (`git hash-object -t commit -w`).  Record name -> SHA in the map.

The final SHA is the replayed branch tip.
When the STACK records a `tip`, verification compares against it;
a STACK without one can still be replayed, just not cross-checked.