fix(batcher): has_enough_balance used current_max_fee + new_max_fee in replacement message

[PatStiles]

has_enough_balance used current_max_fee + new_max_fee in replacement message

Description

Currently the user balance is checked to ensure a user can pay for all there submitted proofs. Currently this check is done before replacement messages are handled and does not compute the total balance of proofs with replacement msg in mind. This leads to issues that when a replacement msg is posted the user balance check will fail as the batcher will check the total accumulated proof including the current msg to be replaced + the fee of the replacement msg. The check will fail as the contribution of the msg being replaced will be counted twice (first in the accumulated balance, and as the next proof added to the batch.

This pr addresses this issue by the following:

• Relocates the user balance check logic to be after the replacement_msg_check
• Creates a separate balance check for replacement msgs that subtracts the original_msg_max_fee from the user_balance

This PR also fixes a bug that was checking replacement_entry_is_valid after closing old sink.

To Test:

First observe the failing case:

• Start a local devnet on staging
• Submit a balance to the batcher with slightly more balance than you would need to submit a new proof.
• Submit using a paying address a proof to the batcher
• Submit using a paying address a replacement msg to the batcher with a higher max_fee
• Observe proof submission fails with an insufficient balance.

Observe the fix:

• Start a local devnet on 'fix/computation-of-replacement-message-accumulated-fee`
• Submit a balance to the batcher with slightly more balance than you would need to submit a new proof.
• Submit using a paying address a proof to the batcher
• Submit using a paying address a replacement msg to the batcher with a higher max_fee
• Observe proof submission succeeds.

Type of change

Please delete options that are not relevant.

• [x] Bug fix

Checklist

• [ ] “Hotfix” to testnet, everything else to staging
• [ ] Linked to Github Issue
• [ ] This change depends on code or research by an external entity
  • [ ] Acknowledgements were updated to give credit
• [ ] Unit tests added
• [ ] This change requires new documentation.
  • [ ] Documentation has been added/updated.
• [ ] This change is an Optimization
  • [ ] Benchmarks added/run
• [ ] Has a known issue
  • Link to the open issue addressing it
• [ ] If your PR changes the Operator compatibility (Ex: Upgrade prover versions)
  • [ ] This PR adds compatibility for operator for both versions and do not change batcher/docs/examples
  • [ ] This PR updates batcher and docs/examples to the newer version. This requires the operator are already updated to be compatible

[github-actions[bot]]

Changes to gas cost

Generated at commit: 98bcbd6e65900f20eff86fc0877241913eb7bdb8, compared to commit: 8b6ef0c71f65d1233d392c2d58f2f1442ba27fab

🧾 Summary (10% most significant diffs)

Contract	Method	Avg (+/-)	%
AlignedLayerServiceManager	createNewTask	+302 ❌	+0.40%

---

Full diff report 👇

Contract	Deployment Cost (+/-)	Method	Min (+/-)	%	Avg (+/-)	%	Median (+/-)	%	Max (+/-)	%	# Calls (+/-)
AlignedLayerServiceManager	5,231,234 (0)	createNewTask receive	56,083 (0) 23,317 (0)	0.00% 0.00%	76,066 (+302) 46,915 (+373)	+0.40% +0.80%	76,217 (-24) 47,195 (0)	-0.03% 0.00%	77,030 (0) 47,195 (0)	0.00% 0.00%	256 (0) 256 (0)

[MauroToscano]

This is stale