fix(explorer): avoid holdings state updates during render

[umeeSthein]

### motivation

The holdings view in the address route was mutating local state during render.

It reset holdings pagination and the show-all toggle when the address changed, and it also clamped the current holdings page during render when the visible asset count shrank. That makes the route fragile and can cause unnecessary rerenders or pagination flicker when holdings data changes asynchronously.

### implications

- move holdings reset-on-address-change into React.useEffect

- move holdings page clamping into React.useEffect

- render address transitions with the default holdings UI state immediately

- reuse the normalized holdings page count for both row slicing and the holdings footer

[o-az]

i reproduced the holdings transition flicker on current main, then checked out/rebased this PR and reran the same browser repro against the dev server.

@umeeSthein the render-time setState cleanup looks correct, but the visible stale-transition flicker still appears to be present after the PR. during client-side navigation, the breadcrumb updates to the new address while the holdings card is still briefly showing the previous address/page state.

before/main repro: https://i.ibb.co/5WWzmJQj/pr805-full-repro.gif

after/this PR repro: https://i.ibb.co/C5DV6mpg/pr805-after-fix.gif

repro steps used:

1. open 0x5818fdDDdb96bCd50bee4253f11B324e7dEA961b?tab=holdings
2. click Show 49 unverified tokens
3. jump to the last holdings page
4. navigate client-side to 0xdf25f88aa6cde9937fdcfcf10fa349528c79dbf9 with tab=holdings

so i think this PR fixes the unsafe render-time state updates, but not the visible stale holdings UI during address transitions.

[umeeSthein]

i reproduced the holdings transition flicker on current main, then checked out/rebased this PR and reran the same browser repro against the dev server.

@umeeSthein the render-time setState cleanup looks correct, but the visible stale-transition flicker still appears to be present after the PR. during client-side navigation, the breadcrumb updates to the new address while the holdings card is still briefly showing the previous address/page state.

before/main repro: https://i.ibb.co/5WWzmJQj/pr805-full-repro.gif

after/this PR repro: https://i.ibb.co/C5DV6mpg/pr805-after-fix.gif

repro steps used:

1. open 0x5818fdDDdb96bCd50bee4253f11B324e7dEA961b?tab=holdings
2. click Show 49 unverified tokens
3. jump to the last holdings page
4. navigate client-side to 0xdf25f88aa6cde9937fdcfcf10fa349528c79dbf9 with tab=holdings

so i think this PR fixes the unsafe render-time state updates, but not the visible stale holdings UI during address transitions.

@o-az thanks for checking and for the repro. I agree this looks like a separate stale-data transition issue, not just the render-time setState cleanup.

I’ll try to reproduce this locally and update the PR. My first pass will be to avoid seeding the current address balances query with loader data from a previous address, roughly:

const { address } = Route.useParams()
const { address: loaderAddress, balancesData } = Route.useLoaderData()

const currentBalancesData =
  loaderAddress === address ? balancesData : undefined

Then the holdings view can stay in its default/loading state until balances for the new address are ready.

[umeeSthein]

i reproduced the holdings transition flicker on current main, then checked out/rebased this PR and reran the same browser repro against the dev server.

@umeeSthein the render-time setState cleanup looks correct, but the visible stale-transition flicker still appears to be present after the PR. during client-side navigation, the breadcrumb updates to the new address while the holdings card is still briefly showing the previous address/page state.

before/main repro: https://i.ibb.co/5WWzmJQj/pr805-full-repro.gif

after/this PR repro: https://i.ibb.co/C5DV6mpg/pr805-after-fix.gif

repro steps used:

1. open 0x5818fdDDdb96bCd50bee4253f11B324e7dEA961b?tab=holdings
2. click Show 49 unverified tokens
3. jump to the last holdings page
4. navigate client-side to 0xdf25f88aa6cde9937fdcfcf10fa349528c79dbf9 with tab=holdings

so i think this PR fixes the unsafe render-time state updates, but not the visible stale holdings UI during address transitions.

@o-az pushed a follow-up for the stale holdings transition case.

The change now only seeds the balances query from loader data when the loader address still matches the current route address. That should prevent the new address page from briefly rendering holdings data/page state from the previous address during client-side navigation.