Use clean context snapshot for ProcessProposal gas validation (CON-173)

[wen-coding]

Summary

checkTotalBlockGas in ProcessProposalHandler reads from processProposalState's context, which can contain stale writes from a previous round's optimistic processing. This PR snapshots a clean context at the start of each ProcessProposal call and uses it for all downstream reads (gas validation, upgrade plan checks, optimistic processing).

How it works

At the start of ProcessProposal, after prepareProcessProposalState sets up the header and consensus params, we branch a new CacheMultiStore from the clean source store (deliverState for block 1, committed root store for blocks 2+). This is a lightweight read-through cache — no data is copied, reads fall through to the parent.

The handler reassigns ctx to the clean snapshot so all downstream reads use it. A defensive error is returned if the clean context is not set up (i.e. if the handler is called directly instead of through ProcessProposal).

Changes

• sei-cosmos/baseapp/abci.go: Snapshot clean context after prepareProcessProposalState, before calling the handler.
• sei-cosmos/baseapp/baseapp.go: Add processProposalCleanCtx field and GetProcessProposalCleanContext() accessor.
• sei-cosmos/baseapp/test_helpers.go: Add SetProcessProposalCleanCtx test helper.
• app/app.go: Reassign ctx from clean snapshot; add comment that ProcessProposalHandler must not be called directly.
• app/app_test.go, app/upgrade_test.go: Convert tests to go through ProcessProposal instead of calling handler directly.
• app/optimistic_processing_test.go: Set up clean context in test setup for internal tests.

Test plan

• TestProcessProposalCleanContextNotAffectedByHandler — verifies writes to processProposalState are NOT visible through clean context
• TestInvalidProposalWithExcessiveGasWanted, TestInvalidProposalWithExcessiveGasEstimates, TestOverflowGas — gas validation tests
• TestSkipOptimisticProcessingOnUpgrade — upgrade detection through clean context
• TestProcessProposalHandlerPanicRecovery — panic recovery via ProcessProposal
• All optimistic processing suite tests pass
• All baseapp tests pass

🤖 Generated with Claude Code

[github-actions]

The latest Buf updates on your PR. Results from workflow Buf / buf (pull_request).

Build	Format	Lint	Breaking	Updated (UTC)
✅ passed	✅ passed	✅ passed	✅ passed	Apr 9, 2026, 4:06 AM

[github-actions]

The latest Buf updates on your PR. Results from workflow Buf / buf (pull_request).

Build	Format	Lint	Breaking	Updated (UTC)
✅ passed	✅ passed	✅ passed	✅ passed	Apr 4, 2026, 9:16 PM

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 58.66%. Comparing base (9bea80a) to head (eef4bb7).
⚠️ Report is 19 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #3197      +/-   ##
==========================================
+ Coverage   58.64%   58.66%   +0.02%     
==========================================
  Files        2055     2055              
  Lines      168494   168601     +107     
==========================================
+ Hits        98810    98916     +106     
+ Misses      60900    60896       -4     
- Partials     8784     8789       +5     

Flag	Coverage Δ
sei-chain-pr	56.09% <100.00%> (?)
sei-db	70.41% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

Files with missing lines	Coverage Δ
app/app.go	68.56% <100.00%> (+0.02%)	⬆️
sei-cosmos/baseapp/abci.go	61.92% <100.00%> (+0.39%)	⬆️
sei-cosmos/baseapp/baseapp.go	78.89% <100.00%> (+3.02%)	⬆️

... and 1 file with indirect coverage changes

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[codchen]

i think we can just assign to ctx here. If ctx is dirty then it probably shouldn't be referenced anywhere below

[wen-coding]

I think that makes sense, had to fix more tests which call ProcessProposalHandler directly (while I think in production we should always go through ProcessProposal).

[wen-coding]

Hmm, tried that and actually it didn't work:
The flow within a single ProcessProposalHandler call:

1. ctx comes in as processProposalState.ctx (the writable store)
2. Line 1222: ctx = cleanCtx — now ctx points to the read-only snapshot
3. Line 1243: app.UpgradeKeeper.GetUpgradePlan(ctx) — reads from clean snapshot, fine
4. Line 1252: goroutine launches, captures ctx
5. Line 1261: app.ProcessBlock(ctx, ...) — writes to the clean snapshot's CacheMultiStore
   Those writes are orphaned. Nobody commits the clean snapshot branch back to processProposalState. When FinalizeBlock later commits processProposalState, the state changes from optimistic processing aren't there.
   So all integration tests now fail with "insufficient fund".

[masih]

Thanks @wen-coding 🙌

[wen-coding]

Ran local docker cluster, stopped and restarted one node, looks happy, submitting