No crate declares an MSRV, so a stable toolchain bump can break the build with no warning

[mallison031]

Repo context. accensa-contracts holds the on-chain half of Accensa: ReceiptAnchor
(Merkle batch anchoring so an agent can verify it was charged correctly without trusting
the seller's API) and RefundVault (policy-bounded refunds without the merchant becoming
a custodian). Both are deployed on testnet. soroban-sdk 27.0.4, MIT. Read README.md,
docs/SECURITY_MODEL.md and DEPLOYMENTS.md before starting.

Problem

No manifest in the workspace sets rust-version, and every CI job installs
dtolnay/rust-toolchain@stable. Together those mean the build is pinned to "whatever Rust
released most recently". When a new stable lands, CI silently moves to it. If it introduces a
new clippy lint, the clippy job fails on a PR that changed nothing relevant; if it changes
codegen, the WASM the workspace produces changes without a commit.

soroban-sdk 27 has its own minimum supported Rust version. The workspace does not record it,
so a contributor on an older toolchain gets a confusing mid-compile error from inside the SDK
instead of a clear "this crate requires Rust >= X".

What to do

• Determine the actual minimum this workspace builds on. Start from the soroban-sdk 27.0.4
  MSRV and verify by building with that exact toolchain — do not guess and do not just copy the
  current stable.
• Add rust-version to [workspace.package] and inherit it in both crates.
• Add a CI job that builds and tests on the pinned MSRV, so the declaration is enforced rather
  than decorative. Keep the existing stable jobs; the point is to test both ends.

Acceptance criteria

• rust-version is declared once in [workspace.package] and inherited by both crates.
• A CI job installs exactly that toolchain (dtolnay/rust-toolchain@<version>) and runs
  cargo build and cargo test.
• Building with a toolchain older than the declared MSRV fails with cargo's own MSRV error, not
  a compile error from inside a dependency.
• The PR states how the MSRV was determined.

[midexol]

@mallison031 please assign

[lamideseun57-netizen]

@lamideseun57-netizen has applied to work on this issue as part of the Stellar Wave Program's 8th wave.

Hi team, I understand the scope here. I am down to work on this issue as part of the Stellar Wave Programs 8 Wave.i Would appreciate if you assign it to me.

ℹ️ Repo Maintainers: To accept this application, review their application or assign @lamideseun57-netizen to this issue.

[afeezorobsco-cyber]

@afeezorobsco-cyber has applied to work on this issue as part of the Stellar Wave Program's 8th wave.

i would like to work on this issue

ℹ️ Repo Maintainers: To accept this application, review their application or assign @afeezorobsco-cyber to this issue.

[Ennyblack]

@Ennyblack has applied to work on this issue as part of the Stellar Wave Program's 8th wave.

i would like to work on this kindly assign me

ℹ️ Repo Maintainers: To accept this application, review their application or assign @Ennyblack to this issue.

[drips-wave]

Congratulations, @Ennyblack! 🎉 Your application was accepted by the repo's maintainers, and the issue is due on August 31, 2026.

🧑‍💻 @Ennyblack: Please resolve the issue such that the repo's maintainers have enough time to review your contribution before the due date. You'll earn Points for completing the issue on-time, which will make you eligible for a share of the Stellar Wave Program's reward pool.

Warning

When opening a PR, please link it to this issue to ensure it gets tracked accurately. Points are awarded when this issue is marked as completed by the maintainer.

🤠 Repo maintainers: Please keep an eye on the contributor's progress and review their work before the due date. You can manage this issue, including adjusting its complexity and points, here.

🌊 Happy Wave 🌊