chainId defaults to 1 for all TRON networks (mainnet/nile/shasta), breaking network disambiguation

[DariRinch]

SDK.__init__ resolves chainId for any TRON network alias (tron, mainnet, nile, shasta) to a hardcoded default of 1 when chainId is not explicitly passed (sdk.py, lines ~74–77):

if n.startswith("tron:") or n in TRON_NETWORK_ALIASES:
    self.chain_type = "tron"
    if resolved_chain_id is None:
        resolved_chain_id = 1

This doesn't break registry address resolution for a single network — _resolve_registries() correctly keys off self.network (the string, e.g. "shasta"), not self.chainId, for TRON. So a single-network client works fine.

But self.chainId is still used elsewhere as if it were a real network discriminator:

• As the key for registry_overrides (Dict[ChainId, Dict[str, Address]]) — there's no way to set different overrides for mainnet vs. nile vs. shasta, since they all collide under key 1.
• As the chainId component of the canonical "chainId:tokenId" agent ID format used throughout the SDK (e.g. the agentId.split(":", 1) check against self.chainId).

Net effect: an agent "1:36" registered on Shasta and a hypothetical agent "1:36" on Nile are indistinguishable by their canonical ID, even though they're different agents on different networks. For any integrator building multi-network support on top of this SDK, the chainId:tokenId format is currently not a safe way to identify which TRON network an agent belongs to.

Suggested fix: either assign real, distinct numeric IDs per TRON network (as is already done for the EVM chains in DEFAULT_REGISTRIES), or make the chain_type == "tron" branch require an explicit chainId rather than silently defaulting to 1.

Confirmed against a real registered agent on Shasta testnet (agent_id = "1:36") — reads work correctly, this is specifically about the ID-scheme ambiguity, not read functionality.