Add a wasm binary-size budget check to CI

[Meshmulla]

Background

These contracts are compiled to wasm32-unknown-unknown and deployed on-chain, where the size of the compiled .wasm binary is not just a build detail — it's a cost and a constraint. Larger contract binaries cost more to deploy and can bump against platform limits. The Cargo.toml release profile is already tuned for small output, which shows size is a known concern; what's missing is anything that notices when the binary grows.

Right now the CI Build & test job produces the release wasm but never checks how big it is. Features and dependencies accumulate over time, and binary size tends to creep upward one PR at a time with nobody watching the total — until a deploy is unexpectedly expensive or rejected.

Why this matters

A size budget turns a slow, invisible creep into an explicit, reviewable event. When a change pushes the wasm past its budget, CI says so in the PR, and the author can decide whether the growth is justified (bump the budget deliberately) or accidental (trim it). It's the same idea as a coverage ratchet, applied to binary size — cheap to add, and it prevents a whole category of nasty deploy-time surprises.

What needs to be done

• After the release wasm build in CI, measure the size of the produced .wasm artifact(s) under target/wasm32-unknown-unknown/release/.
• Compare against a committed budget — a small script, or a documented per-contract threshold — and fail the job when the artifact exceeds it.
• Record the current sizes as the initial budget, with a little headroom, and document them (for example in docs/ or a short wasm-size note) so the number has a home and a rationale.
• Print a friendly size summary in the CI log on every run, so the current size is visible even when it's within budget.

Where to look

• .github/workflows/ci.yml — the Build (release, wasm32-unknown-unknown) step in the Build & test job
• Cargo.toml — the release profile already tuned for small wasm, and the built-artifact path
• soroban/tests/benchmarks.rs — existing size/cost-adjacent tooling worth aligning with

Acceptance criteria

• CI measures the release wasm size and fails when it exceeds the committed budget
• The current sizes are recorded as the baseline budget, with documented headroom
• A human-readable size summary is printed in the CI log on every run
• CI checks must be green before the PR can be merged

Notes

Keep the budget realistic — current size plus modest headroom. The goal is regression detection, not aggressive micro-optimization of the binary.