add tron filtering options to token-selectors

[Prithpal-Sooriya]

Explanation

Currently we have fragmented logic in mobile and extension selectors due to TRON staked assets (energy and bandwidth).
This PR unifies this logic via an optional selector option to filter out TRON staked assets.

Default behaviour is to filter TRON staked assets.

References

Checklist

• I've updated the test suite for new or updated code as appropriate
• I've updated documentation (JSDoc, Markdown, etc.) for new or updated code as appropriate
• I've communicated my changes to consumers by updating changelogs for packages I've changed, highlighting breaking changes as necessary
• I've prepared draft pull requests for clients and consumer packages to resolve any breaking changes

---

Note

Adds an optional (default on) filter to exclude Tron staking resources in selectAssetsBySelectedAccountGroup, with tests and changelog update.

• Selectors:
  • Add Tron resource constants and filtering (TRON_RESOURCE, TRON_RESOURCE_SYMBOLS_SET).
  • Extend selectAssetsBySelectedAccountGroup to accept options { filterTronStakedTokens } (defaults to true) and filter Tron staking tokens across TrxScope networks.
  • Enable memoization for selector args/results via weakMapMemoize.
• Tests:
  • Add Tron fixtures in src/selectors/__fixtures__/arrange-tron-state.ts.
  • Add unit tests validating filtering on/off in token-selectors.test.ts.
• Changelog:
  • Document new optional Tron filtering for selectAssetsBySelectedAccountGroup.

^{Written by Cursor Bugbot for commit e6a0939. This will update automatically on new commits. Configure here.}

[Prithpal-Sooriya]

I really hate this test suite...

Like sure this uses realistic state data, but MAN its ridiculously difficult to add new tests since you need to understand the WHOLE STATE.

It would be much much nicer if we can:

1. Create JSON objects for each state we want to test. We have a fixtures folder that we can shove this in.
2. Break up the selector parts into modular atomic functions that we can mock and test in isolation.

[bergarces]

Ok for now, but I'm not a big fan of this as it can force recalculations based on filters. Also, if we add more chains that have different needs we are going to end up with very messy logic here.

IMO, the problem with Tron should have been solved by expanding the asset type to contain underlying metada (the tron resources), so all these Tron resources would have been added inside the main Tron asset, which will always be present. By adding those "resources" to the list of assets, even though we don't want to display them most of the time, we are causing situations like this one.

[Prithpal-Sooriya]

Yep I 100% agree with this.

R.E. selector recalculations - yep noticed this too. Converted to a weakmap memo on arguments to reduce this. Likewise I decoupled the filtering logic, but I can imagine this selector getting real messy down the line.

TRON tokens are a bit of a mess, I agree it would be good if either:

1. There was a separation between normal tokens and staking tokens
2. Tron team does not expose staking tokens immediately (most flows should not show these tokens), only on some rare screens should they be visible (which can be a separate call not going through our controllers)