fix(explorer): scope tip20-roles config reads to requested chainId

[Joslis]

RFC: Consistent chain selection in /api/tip20-roles

1. Problem Statement

The /api/tip20-roles endpoint accepts a chainId query parameter and uses it
to scope role-membership log reads via tempoQueryBuilder(chainId). However the
TIP-20 config reads (supplyCap, currency, paused, decimals, symbol,
totalSupply, transferPolicyId) were issued through readContracts(config, …)
without a chainId, so they executed against the wagmi default chain.

When a caller supplies a non-default chainId, the response therefore mixes
config from one chain with role data from another. Separately, Number(chainIdParam)
was never validated — a value like ?chainId=abc produces NaN, which then
flows into tempoQueryBuilder(NaN).

2. Background

readContracts resolves each contract entry against its own chainId, falling
back to the connected/default chain when omitted. The two data sources in this
handler (contract reads vs. indexed logs) had diverged because only one of them
was chain-aware.

3. Proposed Change

1. Validate the chainId parameter: it must be a positive integer, otherwise
   respond 400 Invalid chainId.
2. Thread the resolved chainId into every entry of the readContracts call so
   config reads and role-log reads target the same chain.

4. Backwards Compatibility

Requests that omit chainId are unchanged — they continue to use the wagmi
default via getChainId(config). Requests that previously passed a non-numeric
chainId now receive a 400 instead of silently degrading to NaN.