fix: correct merge-base in PR events from git push of pr/ branch

When pushing a pr/ branch, the ahead slice is reversed by callers before
being passed to generate_patches_or_pr_event_or_pr_updates, making it
oldest-first. The tip/first_commit assignments were backwards (using
first()/last() as if the slice were youngest-first), so the merge-base
was computed as the parent of the PR tip rather than the parent of the
oldest commit. Multi-commit PRs therefore showed only 1 commit when
applied via ngit apply.

Adds an integration test that pushes a two-commit large-file PR branch
and asserts the merge-base tag equals the main branch tip.

1 files changed, 1 insertions, 0 deletions

diff --git a/CHANGELOG.md b/CHANGELOG.md
index 31716ff..d4b8083 100644
--- a/CHANGELOG.md
+++ b/CHANGELOG.md
@@ -14,6 +14,7 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
 
 ### Fixed
 
+- `merge-base` tag in PR events generated by `git push` of a `pr/` branch was set to the parent of the PR tip instead of the actual base commit; multi-commit PRs showed only 1 commit when applied via `ngit apply`
 - `git-remote-nostr` list now advertises the newest state event whose OIDs are all confirmed present on a git server or locally, rather than unconditionally using the latest nostr state event; this prevents catastrophic fetch/clone failures when a state event was published before the corresponding git push completed
 - Tag tracking refs written with wrong path (`refs/remotes/origin/refs/tags/v1.0.0` instead of `refs/remotes/origin/v1.0.0`) after a push via `git-remote-nostr`, causing `ngit sync` to fail with "src refspec does not match any existing object" when syncing tags
 - Annotated tag tracking refs stored with the peeled commit OID instead of the tag object OID after a push via `git-remote-nostr`; this caused `ngit sync` to push the wrong object to grasp servers, which rejected it because the nostr state event referenced the tag object OID