feat: Add tron getBlock and getblockInfo for alpaca api

[estrauser-ledger]

✅ Checklist

• npx changeset was attached.
• Covered by automatic tests.
• Impact of the changes:
  • ...

📝 Description

Replace this text by a clear and concise description of what this pull request is about and why it is needed. Be sure to explain the problem you're addressing and the solution you're proposing.
For libraries, you can add a code sample of how to use it.
For bug fixes, you can explain the previous behaviour and how it was fixed.
In case of visual features, please attach screenshots or video recordings to demonstrate the changes.

❓ Context

• JIRA or GitHub link:

---

🧐 Checklist for the PR Reviewers

• The code aligns with the requirements described in the linked JIRA or GitHub issue.
• The PR description clearly documents the changes made and explains any technical trade-offs or design decisions.
• There are no undocumented trade-offs, technical debt, or maintainability issues.
• The PR has been tested thoroughly, and any potential edge cases have been considered and handled.
• Any new dependencies have been justified and documented.
• Performance considerations have been taken into account. (changes have been profiled or benchmarked if necessary)

[github-actions]

⚠️ E2E tests are required

Changes detected require e2e testing before merge (even before asking for any review).

🖥️ Desktop

-> Run Desktop E2E

• Select "Run workflow"
• Branch: feat/tron-getblock
• Device: nanoSP or stax

📱 Mobile

-> Run Mobile E2E

• Select "Run workflow"
• Branch: feat/tron-getblock
• Device: nanoX

Affected coins modules: tron

[Copilot]

Pull request overview

This PR adds Tron block retrieval support to the Alpaca API by implementing getBlockInfo and getBlock (with transaction/operation mapping) and wiring them into the Tron createApi.

Changes:

• Add Tron network typing for blocks-with-transactions and a new network call to fetch them.
• Implement getBlockInfo / getBlock in coin-tron logic, including mapping TRX/TRC10/TRC20-like transfers into BlockOperations.
• Expose these methods through the Tron Alpaca API and add unit tests + a changeset.

Reviewed changes

Copilot reviewed 7 out of 7 changed files in this pull request and generated no comments.

Show a summary per file

File	Description
libs/coin-modules/coin-tron/src/network/types.ts	Adds API types for block headers and blocks with embedded transactions.
libs/coin-modules/coin-tron/src/network/index.ts	Adds getBlockWithTransactions() calling /wallet/getblock with detail: true.
libs/coin-modules/coin-tron/src/logic/index.ts	Re-exports the new block logic entrypoints.
libs/coin-modules/coin-tron/src/logic/getBlock.ts	Implements getBlockInfo/getBlock and transaction→operation mapping.
libs/coin-modules/coin-tron/src/logic/getBlock.test.ts	Adds unit tests for the new block logic (partial coverage).
libs/coin-modules/coin-tron/src/api/index.ts	Wires getBlock/getBlockInfo into createApi() instead of throwing.
.changeset/green-years-sin.md	Declares a minor bump for @ledgerhq/coin-tron.

Comments suppressed due to low confidence (2)

libs/coin-modules/coin-tron/src/logic/getBlock.ts:70

• BlockTransactionAPI.ret is optional, but isSuccess currently treats a missing ret as failure (undefined === "SUCCESS"), which will mark transactions as failed and drop their operations. This is inconsistent with existing Tron parsing in network/format.ts (it defaults missing ret[0].contractRet to "SUCCESS"). Consider computing failed only when contractRet is present and not "SUCCESS" (and still mapping operations when ret is absent).
  libs/coin-modules/coin-tron/src/logic/getBlock.ts:164
• mapTriggerSmartContract introduces TRC20 transfer decoding (methodId parsing, address extraction, BigInt amount parsing), but the new test suite doesn’t cover the successful TRC20 transfer case (and ideally a non-a9059cbb/short-data case). Add unit tests to ensure TRC20 transfers are mapped into two transfer operations with the expected assetReference and amounts.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
90.2% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud