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).

The block was copied verbatim from the ggov SDK and still named GGovRegistry
and its ~5.6KB program / 6144-byte exact ceiling. FracDelegationRegistry is
~2.9KB, so exact sizing gives it a 4096-byte ceiling; the argument for the
spare page is unchanged, only the figures were wrong. Also narrows the
parenthetical to instance apps, which are the only children this registry
spawns.

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).

The guard landed on the ggov-sdk copy only; the two files are meant to be
identical, so the frac registry deploy would still have asked for more extra
program pages than AVM v13 allows and been rejected by the network instead of
by the SDK.

The third page reached the ABI but nothing could use it: createPeriod still read
the box back as two pages, a single app call could only buy 8192 bytes of box
write budget, and both SDK wrappers passed page3 empty.

- createPeriod reads three pages, like createInstance, so a program over 8192
  bytes is no longer truncated at appcreate time. Both read at the running
  offset, so an empty trailing page stays a no-op.
- splitApprovalPages fills all three. Its ceiling is 12282 bytes (3 * 4094),
  which is as much as v13's 16KB total-application-arguments cap allows: four
  encoded pages plus a method selector is over it.
- Box I/O budget is pooled across the group, so the upload spreads the
  references it needs over the upload call plus no-op increaseBudget companions
  — 12 references, two app calls, for a full three-page program.
- addPeriod/addInstance size the group's reference slots from the length of the
  box actually deployed, padding the same way when the read outgrows one call's
  8 slots. At today's sizes (period 4066, instance 6310) neither group gains a
  transaction.

Tests upload a 10000-byte program on both registries — past the 8188 two
arguments carry and past the 8192 one call's references buy — and read the box
back byte-for-byte. Creating an app from a >8192-byte box is not covered: that
needs a valid 12KB TEAL program, which nothing here has.