Add Wasm contract-size regression check per crate in CI

[christabel888]

Context: Same root cause as the clippy CI issue in this batch: gas-regression.yml (Wasm size + gas cost regression checks) existed at the monorepo root with working-directory: ./contracts, and was not carried over by the repo split. It's currently dead in Stellar-inights and absent here.

Where:

• .github/workflows/gas-regression.yml (new in this repo)
• Reference: old version in Stellar-Insightss/Stellar-inights at the same path (adapt the working directory, it's now repo root)

What to do:

• Recreate the workflow: build each crate to wasm32-unknown-unknown --release, record the .wasm size, and fail (or warn) if it grows beyond a threshold vs the previous run.
• Wire in the new benchmarks from this batch (Add benchmark: analytics snapshot submission gas cost in benches/ #42-Add benchmark: governance-voting vote-cast gas cost #44) as the gas-cost side of the regression check once they exist.

Suggested approach:

1. Same starting point as Add CI check enforcing the unwrap/expect/panic clippy deny across all crates #45: adapt the dead gas-regression.yml from Stellar-Insightss/Stellar-inights rather than writing from scratch.
2. For each of the 10 crates, build to wasm32-unknown-unknown --release and record the resulting .wasm file size.
3. Store the baseline (e.g. commit sizes to a checked-in file, or use a CI cache keyed on the previous run) and fail/warn the PR if any crate's size grows beyond a threshold you pick (start with something like 10%, tune later).
4. Wire in the benchmarks from Add benchmark: analytics snapshot submission gas cost in benches/ #42-Add benchmark: governance-voting vote-cast gas cost #44 as a second signal once they exist, so this workflow eventually catches both size and CPU-cost regressions.

Watch out for:

• Wasm size can swing for reasons unrelated to the PR's actual logic change (toolchain version bumps, dependency updates) -- make sure the workflow compares against a same-toolchain baseline, not an arbitrary historical number.
• Don't make the threshold so strict that legitimate feature work (like the event additions in stellar_insights: document submit_snapshot event schema for Soroban Dashboard ingestion #1-upgrade: add upgrade-approved/executed event emission if missing #20) gets blocked by CI for growing the contract by a reasonable amount -- this is a regression guard, not a hard cap.

Definition of done:

• .github/workflows/gas-regression.yml exists and runs on PRs touching contract crates
• Size/gas regressions above threshold fail CI