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.

The issue involves the proof decoding and witness merging logic, likely in modules handling VM proofs and precompile witnesses. Start by examining the changes from PR #3437 and the `PrecompileWitness::merge` method. Look for where root vectors are allocated and where length prefixes are parsed. Write tests for boundary values and malicious inputs as described in the acceptance criteria.

由索引模型根据 Issue 内容生成。