Define and enforce aggregate execution-proof resource limits

## Context

PR #3437 introduces composite execution proofs with VM proof bytes, optional precompile proof bytes, ordered constituent roots, and deferred precompile witnesses. It currently bounds each inner STARK and bounds deferred-state hydration at selected decode entry points, but it does not define one coherent policy for aggregate resources.

This is the successor to prover-api planning ticket 022. The delegated `VmWitness` transport previously called ticket 021 is not a dependency of this work.

Related: #3153 discusses the default size limit for an individual STARK proof. This issue additionally covers outer and aggregate resources and is not blocked on that issue.

## Goal

Define and enforce resource limits before attacker-controlled execution-proof or witness input can trigger unbounded allocation, root folding, hydration, or aggregate merging.

## Scope

- Define whether the public policy uses separate limits or one aggregate budget for:
- encoded execution-proof envelope bytes;
- ordered precompile root count;
- each inner STARK proof;
- deferred witness bytes and hydrated elements;
- merged precompile witness elements.
- Reject an excessive precompile root count during decoding, before allocating the root vector or folding roots with Poseidon2.
- Replace `PrecompileWitness::merge` resetting the insertion budget to `u32::MAX` with an explicit aggregate budget and enforce it across all merged states.
- Make decoder preallocation ceilings and caller-configured acceptance limits explicit and consistent.
- Document which limits are protocol defaults, library safety ceilings, and caller-owned file/network ingestion limits.

## Acceptance

- Malicious length prefixes and excessive root counts fail before allocation or root folding.
- A proof at the configured root-count/envelope boundary still decodes and verifies.
- Aggregate witness merging fails deterministically when the merged state exceeds its configured budget.
- Duplicate roots retain multiplicity and ordered-root semantics under the new bounds.
- Configuring a smaller accepted STARK size does not silently weaken independent allocation ceilings.
- Prover, verifier, VM façade, and deferred-witness documentation describe the same policy.
- Focused tests cover boundary values and oversized untrusted inputs without constructing a STARK unless cryptographic verification is specifically required.