[39] Add a wasm-size budget guard in CI

[merlik787-droi]

Problem Statement

The CI build step succeeds if stellar contract build produces wasm. There is no size assertion, so a regression that adds 50KB to a wasm artifact goes undetected. Soroban contracts have a 64KB wasm size limit near protocol-level; staying well under is essential.

Why It Matters

• Larger wasm means higher deploy cost and lower gas-efficiency headroom.
• Cross-contract deployment cost inflates with size.

Expected Outcome

• New CI step after stellar contract build:

  for wasm in target/wasm32v1-none/release/*.wasm; do
    size=$(stat -c%s "$wasm")
    echo "$wasm: $size bytes"
    [ "$size" -lt 50000 ] || exit 1
  done

• The threshold (default: 50KB) is configurable per contract.
• README documents the budget.

Acceptance Criteria

• CI fails when any contract exceeds its size threshold.
• Reports historical size in a comment via PR bot.

Implementation Notes

• Track size over time in reports/ or via GitHub Pages graph.

Files / Modules Affected

• .github/workflows/ci.yml
• README update per contract.

Dependencies

Issue #15 (per-contract CI matrix).

Difficulty

Easy.

Estimated Effort

1–2 hours.

Suggested Labels

ci, performance, P2

---

[Clement-coder]

Hi,

I’m a full-stack software and blockchain engineer with hands-on experience delivering production-ready solutions across frontend, backend, and blockchain systems.

I’d like to take ownership of this issue. I’ve reviewed the requirements and can implement a scalable, maintainable, and well-tested solution that fully satisfies the acceptance criteria.

Ready to start immediately and keep the team updated throughout the process.

[grantfox-oss]

🦊 GrantFox — @Ebenezer199914 has been assigned to this issue as part of the Official Campaign | FWC26 campaign!

Next steps:

1. Open a Pull Request referencing this issue (e.g., Closes #39)
2. Your PR will be reviewed by the Kqirox maintainers

Good luck! Track your progress on GrantFox.