fix: reject negative extra_pages in appcall transactions

Stage 3 ran one source at a time, so three multi-minute Indexer window
scans summed instead of overlapping. Splitting it by what each half is
allowed to do lets the reads overlap while the writes stay ordered:

- compute (ledger precheck, window scan, replay, manifest assembly) now
  runs concurrently across sources
- ingest stays strictly serial across sources AND instances. uploadAqFile
  derives box names from account ids the frac *registry* allocates as it
  goes, and that counter is registry-wide, so two instances ingesting at
  once would predict the same ids and all but the first would fail with an
  invalid box reference - the same reason the SDK refuses to parallelize
  the batches within one upload.

Compute returns its per-source outcomes rather than pushing onto the run
context, so the report still reads the same on every run (pMap answers in
input order).

Also, on the same path:
- per-instance ledger prechecks fan out; a multi-instance source (reti runs
  one per validator) spent a serial round trip per instance before any scan
- plugins are built once per run and shared by stages 1 and 3; reti was
  resolving every validator's pools twice
- the manifest genesis hash is read once per run, not once per instance
- stage/phase timings behind the debug flag, so this is measurable at all

The account page paid a fan-out on two axes and a waterfall between
them: one committee-snapshot read per instance, then - once those
landed and syncedIds could be derived - one AQ read per committee.
On VotingPowerByCommittee, which passes every gGov committee, that is
~33 queries in two phases for a 3-pool account.

Fold both axes into the read that already spans instances:

- FracAccountCommitteeAq gains totalVotes, taken field-wise off the
  committees box getAccountCommitteeAq already reads to resolve
  committeeNumId - so it costs no extra box read and no extra
  reference. Field-wise rather than cloning because escrowsVotes sits
  between the two fields and grows with the escrow count, the same
  reasoning getCommitteeStanding documents.
- logAccountInstanceAQ takes committeeIds[] and logs one row per
  (instance, committee) pair, instance-major. Every row already echoes
  its committeeId, so callers group rather than index-align. It also
  gains the deleted-app probe its sibling logInstanceCommittees has -
  free, since the app is referenced by the inner call anyway, and today
  one deleted instance takes down the whole page.

References now split per-instance and per-pair, so the page size is a
function of the committee count:

    refs(I, C) = 1 + I*(2 + 3C) <= 128

C=1 gives 25, reproducing the old AQ_PAGE_SIZE exactly. C=42 fits no
instance at all, hence aqMaxCommitteesPerCall = 41 alongside
aqRefBudget. getAccountInstanceAQs sizes the two axes against each
other rather than paging instances serially - committee chunks are
independent and run in parallel. Given the caller's instance count it
solves for instances first; without it, for committees, which keeps the
single-committee callers at exactly the one round-trip they cost today.

Frontend: usePooledCommitteeAqs collapses to a single useQuery, the
syncedIds pre-filter disappears (it only existed to avoid the
per-committee cost), and poolVotes reads entry.totalVotes.
useFracInstanceCommittees becomes usePoolSyncedCommittees - a plain
useQuery for PoolDetail's account-independent "Voting since" row, the
one caller no account-scoped reader can serve.

Measured on localnet at 30 committees x 2 pools: 32 algod calls in two
phases -> 3 (one account read plus two parallel AQ chunks), 130ms ->
24ms. Instance approval program 6,427 -> 6,453 / 8,192 bytes.

BREAKING: getAccountCommitteeAq's return type changes, and with it its
ARC-4 selector, which the registry inner-calls by selector; and
logAccountInstanceAQ's own signature. Registry and every live instance
must be upgraded together. No deployed registry today - neither
.env.testnet nor .env.mainnet carries VITE_FRAC_REGISTRY_APP_ID.

The pool page's vote-record read was the only frac batch reader packing one call
per account into a simulate group, which capped it at the group's 16-transaction
capacity - an order of magnitude under what a single call can carry. The instance
had no plural reader for votingRecords, unlike accountAq, which logAccountAqs has
served all along.

logVotingRecords is that sibling, and the SDK now chunks it the way it chunks every
other log reader: 63 ids per call, two calls per simulate group. What binds a call
at 63 here is the log budget rather than references, which is new - allowMoreLogging
lifts a call's total to 65,536 bytes and a record cannot exceed ~950, so 63 rows is
~59.9KB. The other readers arrive at the same 63 from the 2048-byte app-arg cap, so
the number is a coincidence worth writing down.

PoolDetail's page size was 10 precisely because of the 16-call ceiling; it goes to
25, matching the committee leaderboard, with the page still costing one round-trip.

getVotingRecords had no test anywhere - its only caller was the frontend - so this
adds the first: index alignment across voted, ingested-but-silent and unknown
accounts, and a 129-id stress placing voters at the first, middle and last slots to
prove the aggregate stays aligned across the 126-per-group boundary. The alignment
test also pins the decoded numeric type, because the batch path decodes the struct
out of a log rather than taking the client's typed return, and a bigint there would
break every arithmetic consumer.

Costs 85 bytes of the instance's approval program, which is at 6,427 of 8,192 with
extraProgramPages already at the AVM maximum.

Six-seat zuss (8/9 seats), written under the blindness clause of
PREREG_v41-release-replicate.md 3a(3): methodology only, no session
values. Majority locks Option (a) - crop-shape is NOT part of the
synthetic-control hypothesis, because a synthetic crop null cannot
calibrate or gate the Falcon crop/SHAPE path (non-transfer); the interim
raw-line ruling becomes permanent under it. The minority Option (b) draft
(matched synthetic null family + planted-shape positive control with a
numeric fire condition) is kept in full with the founder decision
criterion, because the split is real. Takes force only as a dated
pre-registration after the release-replicate decision, in the ruled order.

Security Impact: document only, explicitly not in force; no rule changes
until adopted.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>