The previous commit gated the top-up on balances and stopped there. The
re-review found the gap that leaves, and it is worse than the one it
replaced: a balance that fails to arrive pushes the requirement *up* (the
child looks empty), but a roster or pool standing that fails to arrive
pushes it *down* — the rows are dropped and `[].every()` still reports
resolved. So a frac registry whose `fetchCommitteePools` errored read as
"fully covered" at a requirement nothing had priced, and the provisional
notice told the operator the number was an over-estimate in exactly the case
where it was not.

`resolved` now covers every input each estimate was built from — periods,
committees, delegations, both rosters, `mbrTopUp`, the frac key length, every
counted committee's pools, and the balances. The reads keep their `data`
possibly-undefined for that reason: an empty roster and an unread one are
indistinguishable once defaulted. `isError` likewise spans every query rather
than the balances alone, and only picks the wording — the gate is `resolved`,
which is false for an absent input however it came to be absent.

The callout no longer claims a direction, since one flag now covers both.

Two more from the same review:

- `countsTowardMbr` used `nowSeconds <= votingEnd`, counting a period as
  fundable for one second after the contracts stop admitting votes
  (`Global.latestTimestamp < votingEnd`, ggovPeriod.algo.ts:408 and
  fracDelegationInstance.algo.ts:962). Now strict, with the check script
  pinning the boundary rather than the off-by-one.
- `poolSignature` keyed only on instance ids, so a staker count that moved
  between refetches left the memo — and the figure — on the previous count.
  It now carries every field `poolRowsOf` keeps.

The estimator already computed a `resolved` flag on every row and every
estimate — "so `required` is final rather than provisional" — and nothing
read it. Three review findings on #117 are three ways of falling through
that gap:

- the top-up button stayed armed while the panel loaded, and an unread
  registry balance falls back to zero spendable, so it offered to send the
  whole requirement;
- an *errored* balance read is not a pending one, so `isLoading` went false
  with the entry simply missing from `byAppId` — the same zero, permanently;
- the frac vote-record key length was absent from the composite loading
  state, and without it the pool list is empty, which makes the frac
  registry read as fully covered at a requirement of zero.

Wire the flag through instead of patching each symptom. `useAppAccountInfos`
now reports `isError` alongside `isLoading`, following the convention
fracQueries.ts already sets for reads whose empty result cannot carry the
difference. `RegistryMbr` gains `resolved` — the registry's own balance plus
every child's, with the frac key length folded in because its absence is
invisible to `[].every()`. The panel shows the figures either way, since an
unread balance can only push a requirement up, but replaces the coverage
callout with a provisional notice and will not offer to fund it.

New `Balances incomplete` story covers the state the panel previously could
not express.

Connected address can be used for swapping and/or dust sweep even if it's inside a bundle

feat: registries open their boxes to foreign reads at create