feat(tron): add TRC20 approval resource sponsoring extension

[boboliu-1010]

Description

Adds the TRC20 Approval Resource Sponsoring extension on top of the released v1.1.0 baseline, targeting the v1.2.0 release of the TypeScript Extensions and TRON packages.

This PR:

• carries forward the x402 v2 specification migration from docs: migrate and update x402 v2 specifications #81;
• defines the TRC20 approval resource sponsoring protocol and wire format;
• implements client, server, and facilitator extension hooks;
• validates the exact signed approval transaction before broadcast;
• delegates and reclaims TRON Energy and Bandwidth around approval;
• requires an intent-aware Resource Owner signer, a non-owner Active Permission, and strict local JSON/protobuf validation before and after signing;
• durably recovers every non-terminal sponsorship state and only replaces an Undelegate after its original txID is confirmed failed;
• submits Undelegate recovery debt before continuing Permit2 settlement, while confirmation and capacity release run asynchronously;
• adds unit, integration, and repeatable Nile end-to-end examples;
• adds changesets for minor releases of @bankofai/x402-extensions and @bankofai/x402-tron.

Tests

• Core: 649 tests passed
• Extensions: 531 tests passed
• TRON: 215 tests passed
• Core, Extensions, and TRON CJS/ESM/DTS builds passed
• Facilitator example TypeScript check passed
• TRON lint and formatting checks passed
• Nile fresh-wallet end-to-end flow passed: activation, funding, verification, resource delegation, approval, Permit2 payment settlement, asynchronous recovery reconciliation, and zero remaining delegation
• Nile settlement transaction: c5b08dbb68db496a97314a4eb82c3e7a53429ebed9d3182f424c6f0420bfd84c

Checklist

• I have formatted and linted my code
• All new and existing tests pass
• My commits are signed (required for merge)

[Will-Guan]

Request changes. The sponsorship architecture is directionally sound, but these six confirmed issues should be addressed before release:

• CR-001 allows the Permit2 authorization to expire after sponsorship side effects but before payment settlement, creating a direct Resource Owner cost-without-payment path.
• CR-002 makes the stock Client incompatible with the Facilitator's solidified mode because Approval lifetime is neither negotiated nor configurable end to end.
• CR-003 permanently caches a transient permission RPC rejection, disabling both new sponsorships and potentially required recovery until the process is rebuilt.
• CR-010 exposes an unbroadcast Approval identity as the failed settlement transaction, violating the response contract and misleading downstream tracking.
• CR-013 lets a network-bound signer registered under tron:* process another network's requirements without an explicit network equality check.
• CR-020 is a lower-severity design correction: Approval update behavior should be an explicit per-token policy shared by sponsored and self-funded paths. The current v1 approval_reset_required fail-closed behavior is reasonable and should not be replaced with an implicit reset transaction.

I also recommend holding the release until TRON Upto and Batch Settlement support is implemented. Resource Sponsoring should be integrated through shared scheme-neutral hooks rather than remaining an Exact-only special path, and release coverage should demonstrate the same admission, deadline, network binding, Approval policy, response semantics, idempotency, and recovery invariants across Exact, Upto, and Batch Settlement.

Before release, please add end-to-end matrices for Exact/Upto/Batch × packed/solidified, token Approval strategies with zero/partial/sufficient allowance, cross-network signer rejection, transient permission RPC recovery, pre-Approval failures, and deadline expiry at each sponsorship stage. This release recommendation is a scope/readiness recommendation, not an additional confirmed defect.

[roger-gan]

参考原有设计，env文件就放一个好了，不要区分client，server，facilitator

[roger-gan]

这些为啥不放配置文件？

[roger-gan]

整个流程耗时对比原有会增加多少，考虑一般和最坏情况

[roger-gan]

整个reconcile机制是基于持久化的，假如持久化出问题怎么办