fix: annotated tags missing from list due to dropped peeled refs

RepoState::try_from was explicitly discarding all refs/tags/*^{} entries
("peeled" refs) when parsing the nostr state event. This meant the list
command only advertised the tag object OID, but git requires two lines for
annotated tags:

  <tag-object-oid> refs/tags/v1.0.0
  <commit-oid>     refs/tags/v1.0.0^{}

Without the ^{} peeled line git cannot resolve the tag to a commit, so
git fetch --prune treats it as unresolvable and deletes it.

The nostr state event already stores both entries correctly (written by
generate_updated_state in push.rs). The fix simply stops try_from from
discarding the ^{} entries on read, so they flow through to the list
output unchanged.

1 files changed, 1 insertions, 0 deletions

diff --git a/CHANGELOG.md b/CHANGELOG.md
index cbf5312..f52d353 100644
--- a/CHANGELOG.md
+++ b/CHANGELOG.md
@@ -18,6 +18,7 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
 
 ### Fixed
 
+- Annotated tags missing from `git-remote-nostr` list output; peeled `^{}` refs were stripped when parsing the nostr state event, so git could not resolve the tag to a commit and `git fetch --prune` deleted it; existing repos with affected state events are self-healed on the next push
 - Fallback signer relays updated: replaced `nsec.app` with `bucket.coracle.social` and `nos.lol` for nostrconnect resilience
 - `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