Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@crates/actors/src/block_migration_service.rs`:
- Line 163: Replace the unchecked cast "rollback_count as usize" with a checked
conversion using TryFrom/TryInto: compute a capacity via "let capacity =
usize::try_from(rollback_count)?;" (or "let capacity =
rollback_count.try_into()?;" if using std::convert::TryInto) and then call
"Vec::with_capacity(capacity)"; if the surrounding function doesn't return
Result, propagate or handle the conversion error appropriately (e.g., map it
into the function's error type and return early). This change touches the
"rollback_count" conversion and the "rollback_infos" initialization
(Vec::with_capacity).

In `@crates/actors/src/chunk_migration_service.rs`:
- Around line 169-183: The preflight canonicality check using
block_index.get_item in the chunk migration handler is vulnerable to TOCTOU with
recover_from_network_partition; add a shared serialization point between
recovery and migration (either a migration generation/epoch or a shared lock)
and validate that generation/lock after the check and immediately before any
writes so stale BlockMigrated messages cannot re-create cleared state.
Concretely: introduce a migration_epoch (or use an existing RecoveryManager)
that is incremented by recover_from_network_partition, read the epoch in the
handler (alongside the block_index.get_item check) and re-check the epoch
immediately before performing index/chunk writes (or acquire the same
Mutex/RwLock used by recovery around validation+write). Update the chunk
migration code paths (the BlockMigrated handler and any functions that mutate
indexes/chunks) to abort when the epoch changed or lock cannot be held.

In `@crates/chain-tests/src/multi_node/partition_recovery.rs`:
- Around line 405-409: The verification vector uses the wrong ledger for
peer_publish_tx; replace DataLedger::Submit with DataLedger::Publish in the
peer_unique_txs definition so the tuple for peer_publish_tx matches the ledger
it was posted to (peer_publish_tx, DataLedger::Publish), keeping the other
entries (peer_one_year_tx -> DataLedger::OneYear, peer_thirty_day_tx ->
DataLedger::ThirtyDay) unchanged.
- Around line 342-346: The tuple list shared_txs uses the wrong ledger for
shared_publish_tx (it currently pairs shared_publish_tx with
DataLedger::Submit); update the tuple so shared_publish_tx is paired with
DataLedger::Publish (i.e., change the first tuple to (DataLedger::Publish,
&shared_publish_tx)) so the verification code (using shared_txs) queries the
same ledger that created the transaction.

---

Outside diff comments:
In `@crates/domain/src/models/storage_module.rs`:
- Around line 1631-1641: The function make_range_partition_relative currently
subtracts storage offsets from chunk_range directly which can underflow; change
it to first compute the intersection between chunk_range and the storage module
range (using the same pattern as index_transaction_data, e.g. let intersection =
chunk_range.intersection(&storage_module_range) or the project’s equivalent),
return an error if there is no intersection, then compute relative offsets from
that intersection (let start = intersection.start() -
storage_module_range.start(); let end = intersection.end() -
storage_module_range.start()) and construct the PartitionChunkRange from those
relative values; keep references to get_storage_module_ledger_offsets and
make_range_partition_relative to locate the change.

Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@crates/chain-tests/src/multi_node/partition_recovery_epoch_boundary.rs`:
- Around line 26-29: Change this test to start from the shared testing builders:
call NodeConfig::testing() to create genesis_config (instead of
NodeConfig::testing_with_epochs) and then set the epoch length on its consensus
config via consensus = ConsensusConfig::testing() with the epoch length override
(num_blocks_in_epoch) and set chunk_size explicitly on
genesis_config.consensus.get_mut().chunk_size = 32; in short, replace the
testing_with_epochs path by creating genesis_config = NodeConfig::testing(),
build or derive a ConsensusConfig::testing() with the desired epoch length,
assign/merge it into genesis_config.consensus, and then set chunk_size on
genesis_config.consensus.get_mut().

Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@crates/actors/src/block_tree_service.rs`:
- Around line 685-698: The code currently casts usize -> u32 with `as` for
old_fork_blocks.len() and new_fork_blocks.len(); replace those with checked
conversions using TryFrom/TryInto (e.g. `let old_len: u32 =
old_fork_blocks.len().try_into()?; let new_len: u32 =
new_fork_blocks.len().try_into()?;`) and then use `old_len`/`new_len` in the
error! call and the subtraction; ensure you handle the conversion error (map to
a sensible error return or log and early-return) so the function’s error type or
control flow remains correct; update references to
`self.config.consensus.block_migration_depth` comparisons to use the converted
values or convert that config value to the same type before comparing.

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@crates/chain-tests/src/multi_node/partition_recovery.rs`:
- Around line 185-191: The test discards the return from post_tx_with_chunks
when posting genesis_publish_chunks so the orphaned Publish/Submit data_root
from the genesis minority fork is never checked; capture and save the result of
post_tx_with_chunks(&genesis, &genesis_signer, &genesis_publish_chunks,
DataLedger::Publish).await? into a variable (e.g., genesis_publish_tx) and add
that variable to the genesis_orphaned_txs collection alongside
genesis_one_year_tx and genesis_thirty_day_tx so the data_root from the genesis
Publish path is asserted cleared during recovery (mirror the existing
winning-fork re-index checks).
- Around line 458-478: After the two mine_block().await? calls in the
continued-operation phase, wait for the block index migration to complete before
reading genesis.get_block_index_height(): call
genesis.wait_until_block_index_height(peer_height + 2). Then read
final_index_height and proceed with the supply checks (use the same
genesis.get_block_index_height(), final_supply via
genesis.node_ctx.supply_state_guard.get(), and the existing loop over block
heights) so the assertions won't race with asynchronous BlockMigrated
processing.