SPM installs 4.2.9 binary for every version: root Package.swift on master is stale (last updated ~1 year ago)

[LeeeeSuHyeon]

Describe the bug
The root Package.swift committed on master has not been updated in ~1 year and still pins its binaryTarget URLs/checksums to the 4.2.9 release. Every tag since 4.2.9 (verified 4.3.0 → 4.7.3) inherits this stale manifest.

Since Swift Package Manager resolves a package by git checkout and reading the manifest committed in that tree — it never reads the Package.swift attached as a release asset — every SPM consumer downloads the 4.2.9 xcframework regardless of the version it resolves. Package.resolved/Xcode report e.g. 4.7.3, but the linked binary is actually 4.2.9, so any API added after 4.2.9 is missing at compile time (e.g. TronSigningInput.rawJson, RippleSigningInput.rawJson).

Direct download of the release zip works fine, because each release does ship an up-to-date WalletCore.xcframework.zip and a correct Package.swift release asset — only the committed tree manifest is never updated. This looks like a release-pipeline gap: the per-release manifest is generated and attached to the release, but never committed back into the repository tree.

To Reproduce
Steps to reproduce the behavior:

1. Add the package via SPM:
   .package(url: "https://github.com/trustwallet/wallet-core", exact: "4.7.3")
2. Resolve. Package.resolved / Xcode shows 4.7.3.
3. Use an API introduced after 4.2.9:
   _ = TronSigningInput.with { $0.rawJson = "" }
4. Compile error:
   Value of type 'TronSigningInput' (aka 'TW_Tron_Proto_SigningInput') has no member 'rawJson'.
5. Inspect the resolved checkout manifest at
   ~/Library/Developer/Xcode/DerivedData/<proj>/SourcePackages/checkouts/wallet-core/Package.swift
   → its binaryTarget URLs point to .../releases/download/4.2.9/....

Expected behavior
The committed root Package.swift (on master and each release tag) should reference that version's xcframework URLs and checksums — matching the correct Package.swift already published as a release asset. For 4.7.3, https://github.com/trustwallet/wallet-core/releases/download/4.7.3/Package.swift is correct. Resolving 4.7.3 via SPM should link the 4.7.3 binary.

Screenshots
N/A — evidence is the manifest diff below.

Additional context
Manifest comparison for 4.7.3:

Committed tree (what SPM reads) — STALE / WRONG:

WalletCore → releases/download/4.2.9/WalletCore.xcframework.zip     checksum 651894a9…
Protobuf   → releases/download/4.2.9/SwiftProtobuf.xcframework.zip  checksum 946efd4b…

Release asset (not read by SPM) — CORRECT:

WalletCore              → releases/download/4.7.3/WalletCore.xcframework.zip              checksum 179b1276…
WalletCoreSwiftProtobuf → releases/download/4.7.3/WalletCoreSwiftProtobuf.xcframework.zip checksum 875e4d9f…

Notes:

The Protobuf artifact was also renamed (SwiftProtobuf.xcframework.zip → WalletCoreSwiftProtobuf.xcframework.zip), so the stale committed manifest additionally points at an outdated artifact name.
Impact: SPM consumers cannot obtain any binary newer than 4.2.9 through the official package URL. The mismatch is silent — Package.resolved shows the requested version while the linked binary is 4.2.9 — until a post-4.2.9 API is used. Current workarounds (forking the repo or declaring a local binaryTarget wrapper) are not discoverable.
Affected: master and all releases 4.3.0 → 4.7.3.

Environment

Integration: Swift Package Manager (Xcode)
Requested version: 4.7.3 (resolved), linked binary: 4.2.9
Verified against master and tag 4.7.3 via the GitHub Contents API

Proposed fix
I'm opening a PR that updates the committed root Package.swift to the 4.7.3 URLs/checksums (matching the release asset, including the renamed Protobuf artifact). Longer term, the release automation should commit the regenerated manifest back to the tree on each release so this stays in sync