* changelog: cut the Pending section as 0.7.2, and record 0.7.1

v0.7.2 was tagged at b46a463 so that stellar-rpc, Horizon and Galexie
v28.0.0 all pin a released SDK tag for Protocol 28; Horizon had been
pinning a pseudo-version to get #5974. Everything the Pending section
listed ships in it, with two corrections:

* the `protocols/rpc` GetHealthResponse close-time fields (#5958) moved to
  [0.7.0] — that commit is an ancestor of the v0.7.0 tag, so it has been
  released since 2026-08-03.
* added a [0.7.1] section for #5966 and #5970, which were tagged on
  2026-08-04 without a changelog entry, so 0.7.2 does not absorb them.

The ingest/ and txnbuild/ sub-changelogs still carry Pending sections whose
contents span several released versions; untangling those is left alone
here.

* ingest: ApplyLedgerMetadata closes the datastore and ledger backend and
  propagates the PrepareRange error, so an early return no longer strands a
  goroutine per worker and a failed prepare no longer passes silently.
* go.mod: the go-xdr bump to dc590f1, which fixes decoder bound handling for a
  variable-length field whose length prefix ends the input. 0.6.1 recorded this
  bump under Updates; 0.7.2 carries the same one.

Co-authored-by: Claude Opus 5 (1M context) <[email protected]>

* xdr: export LedgerCloseMetaView.LedgerHeader

* changelog: link PR

…ent data (#5983)

A Soroban UDT struct (`#[contracttype]`) encodes an `Option` field holding
`None` as a map key bound to `Void`. CAP-0067 instead specifies that
`to_muxed_id` is simply absent when a transfer has no muxed destination, and
that form already parsed.

The `Void` form did not. It fell through to the `default:` arm and failed the
parse, and callers discard an event that fails to parse rather than surfacing
the error, so the entire transfer event vanished from the stream over a field
carrying no information. A contract reaches that path by publishing its event
data as a struct with an `Option` field, which is the natural way to write it.
CAP-0086 (protocol 28) adds host functions that omit such a key instead, so the
same struct built with the v28 SDK now produces the compliant encoding.

Co-authored-by: Claude Opus 5 (1M context) <[email protected]>

…tes (#5985)

A to_muxed_id of type ScvBytes was copied into a fixed 32-byte buffer, so a
shorter value was right-padded with zeroes and a longer one truncated to its
first 32 bytes. Either way the event reported a muxed id the contract never
emitted, silently and with no way for a consumer to tell it apart from a real
32-byte value.

The idiom came from NewMuxedInfoFromMemo, where the source is an xdr.Hash and
the fixed size is therefore exact. Here the source is an xdr.ScBytes of any
length: only a classic transaction memo maps to 32 bytes, while a contract may
put any byte string in to_muxed_id. MuxedInfo_Hash.Hash is a []byte, so report
what was emitted and let the consumer decide what to make of it.

Fixes #5984

Co-authored-by: Claude Opus 5 (1M context) <[email protected]>

Co-authored-by: Nearx-Labs <[email protected]>