This will fail CI until
https://github.com/algorand/algorand-sdk-testing/pull/327 is merged

Should ideally merge
https://github.com/algorand/algorand-sdk-testing/pull/327 first so we
can continue to use master

fix(ci): validate SDK-dependent projects after the SDKs are built

The committee-uploader and frac-delegation-pipeline validate steps ran
immediately after `pnpm install --ignore-scripts`, but both link to
ggov-sdk / frac-delegation-sdk, whose `dist/` is gitignored and only
produced by the later "Build SDKs" step. Their typecheck (and the
pipeline's test run) therefore resolved against SDK builds that did not
exist yet.

Move both steps below "Build SDKs" so their dependencies are present.

AVM v13 relaxes box isolation: an app can opt its boxes into reads by any other
app. Both registries now do that in a new createApplication, which runs
app_params_set(appForeignBoxReads, true). Verified on localnet that the opcode is
permitted during the creating call itself, so no separate post-create step is
needed - the v13 notes describe enabling access as update-then-run, but that is
for apps already deployed.

Reads only; writes stay exclusive to the owning app. app_params_set is run by an
app on itself, so a contract that is not updatable can never opt in later, which
is what preserves intentional immutability.

The create is a real ABI method rather than a bare one. It lands in the ARC-56 and
the generated clients, it can take arguments later without changing the create
shape a second time, and it matches the house style - FracDelegationInstance
already has an ABI createApplication invoked by selector from the registry
factory. Both createRegistry paths switch from create.bare() to the method call;
every other caller routes through createRegistry.

Two consequences of the create no longer being bare, both found by the suite:

- deployRegistryWithoutBytecode in the period e2e spec deploys a registry
  directly and was still doing a bare create, which is no longer routed and fails
  with an err on the OnCompletion match.

- The ATST unit specs. ATST holds a contract with any create method in
  `isCreating` and rejects every ABI call with "method can not be called while
  creating" until a create method runs - but ATST 1.2.0 predates v13 and cannot
  execute app_params_set, so the real body cannot run in the emulator. The
  registry test subclass overrides createApplication with a no-op and calls it
  after construction; the opt-in itself is covered e2e.

Follow-up worth taking: with foreign reads on, much of the registries' readonly
getter and log-dumping surface (getDelegation, getPeriodSummary, logCommitteePages,
getEscrow, ...) exists only because cross-app box reads used to be impossible.
Not touched here.

Suite green: 539 passed (2 new).

Both registries pinned extraProgramPages at 3 - the old AVM maximum - on the
reasoning that pages could never be added later, so every spawned app rented the
full 8KB whether it needed it or not. AVM v13 lifts the ceiling to 7 pages (16KB)
and lets an update add pages, so the constant is now just overpayment.

The inner appcreate in createPeriod/createInstance derives pages from the length
of the bytecode actually being deployed. Deliberately measured against the BOX
rather than compile(Child).extraProgramPages: the box is the source of truth for
what is being created, and it exists precisely so child code can be upgraded
without redeploying the registry - sizing off the build-time compile would
under-allocate the moment a newer, larger program is uploaded. Schema has no
box-derived equivalent, which is why the two are sourced differently.

Effect at current sizes: period apps 3 -> 1 extra pages (200k microAlgo saved per
period; the v13 compiler shrank GGovPeriod to 4070 bytes, which is why this is 1
and not the 2 a pre-upgrade measurement would suggest), instances unchanged at 3.

createRegistry sizes the registries the same way but keeps ONE spare page. Sized
exactly, GGovRegistry would get a 6144-byte ceiling for a ~5.6KB program - tighter
than the 3 pages it carries today - and adding pages later is the one thing
factory.deploy cannot do: it treats "existing pages < needed" as a schema break
whose only remedies are failing or creating a NEW app. Without the margin, the
next time the program crossed that ceiling a routine createRegistry({update:true})
would start failing with "Schema break detected". Net: GGovRegistry stays at 3,
FracDelegationRegistry drops 3 -> 2. Spawned apps need no such margin - the
registry re-sizes each one from its approval box at every create.

The page assertions in the specs now compute the expected value from the app spec
instead of pinning a literal, so they track the contract rather than needing an
edit every time it changes size.

Note the plan called for reusing algokit-utils' calculateExtraProgramPages. It is
declared in the .d.ts but missing from the package's exports map, so importing it
typechecks and then throws ERR_PACKAGE_PATH_NOT_EXPORTED at runtime. Each SDK gets
a small local util/extraProgramPages.ts instead, matching how the two SDKs already
duplicate shared helpers.

Suite green: 537 passed.

feat: pooled voting pool detail