refactor(vara.eth/processor): apply MB transactions as an ordered list

[grishasobol]

Resolves #5501

Summary

• Replaces the processor's per-field block inputs (injected_transactions, events, gas_allowance) on ExecutableData with a single ordered Vec<ProcessorTransaction>, so the processor applies MB transactions in the exact order the malachite block sequenced them.
• ethexe-compute now maps each malachite::Transaction 1:1 into a ProcessorTransaction, resolving AdvanceTillEthereumBlock into the concrete Ethereum events it pins (compute has DB access).
• Processor::process_programs iterates the transaction list dispatching EthereumEvents / Injected / ProgressTasks / ProcessQueues; handle_injected_and_events is split into handle_events + handle_injected. The promise sink is take()n by the single ProcessQueues transaction.

Notes

• Adds assert_migration_types_hash doc explaining why migration types must stay byte-stable.
• db.rs type-info hash updated to reflect the ExecutableData shape change.

Test plan

• cargo nextest run -p ethexe-processor
• cargo nextest run -p ethexe-compute
• cargo nextest run -p "ethexe-*" --no-fail-fast

🤖 Generated with Claude Code

[gemini-code-assist]

Summary of Changes

Hello, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request refactors the processor's execution pipeline to enforce strict transaction ordering. By consolidating disparate input fields into a unified, ordered list of transactions, the processor now processes events, injected transactions, and queue tasks in the precise sequence determined by the Malachite block. This change improves determinism and simplifies the execution logic within the processor.

Highlights

• Processor Transaction Refactoring: Replaced individual fields (injected_transactions, events, gas_allowance) in ExecutableData with a single ordered Vec to ensure transactions are applied in the exact sequence defined by the Malachite block.
• Compute Layer Updates: Updated ethexe-compute to map Malachite transactions 1:1 into ProcessorTransactions, resolving AdvanceTillEthereumBlock into concrete events during the mapping process.
• Migration Safety: Added assert_migration_types_hash to enforce byte-stability for SCALE-encoded types, preventing silent database corruption during migrations.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize the Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counterproductive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for GitHub and other Google products, sign up here.

Footnotes

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[gemini-code-assist]

Code Review

This pull request refactors the ethexe execution model to use an ordered list of ProcessorTransactions within ExecutableData, replacing the previous approach of handling events, injected transactions, and gas allowances in fixed sequential stages. This change allows the processor to apply transactions exactly as they were sequenced in a Malachite block. Feedback focuses on ensuring the promise_sink is handled robustly to support multiple queue-draining transactions per block and optimizing the compute layer to avoid emitting empty event transactions.

[gemini-code-assist]

Using promise_sink.take() is brittle as it assumes only one ProcessQueues transaction exists per block. While the current sequencer might follow this "MB shape", the refactor's goal is to support an ordered list of transactions. If a block contains multiple ProcessQueues transactions (e.g., interleaved with other transactions), any injected transactions processed in subsequent drains will fail to emit promises because the sink was consumed by the first one. Using clone() (assuming BoundPromiseSink is clonable, which it should be as it wraps a channel sender) makes the processor more robust and truly generic.

                    self.process_queues(
                        transitions,
                        height,
                        timestamp,
                        limits.gas_allowance,
                        promise_sink.clone(),
                    )

[gemini-code-assist]

Pushing a ProcessorTransaction::EthereumEvents when the events list is empty is unnecessary and adds a small overhead to the processor loop (which will create a ProcessingHandler only to do nothing). It's better to skip it if no events were collected during the advance walk.

Suggested change

	processor_txs.push(ProcessorTransaction::EthereumEvents { events });
	if !events.is_empty() {
	processor_txs.push(ProcessorTransaction::EthereumEvents { events });
	}