fix: use abi.encode for sender in CCIPLocalSimulatorFork v1.6 messages

[kurogami-ibrahim79]

Fixes #62.

Description
This PR addresses the byte-length mismatch issue for the sender field in CCIP v1.6+ simulated messages.

Previously, CCIPLocalSimulatorFork._executePostV1dot6 utilized abi.encodePacked(message.sender), which resulted in a 20-byte string. On production EVM source chains for v1.6 lanes, this field is expected to be a 32-byte ABI word, matching the fix previously applied in #52 for receiver, destTokenAddress, and sourcePoolAddress.

This mismatch caused the receiver contract to revert when executing abi.decode(message.sender, (address)) or to fail trustedRemote validations due to byte misalignment.

Changes Made

• Updated sender: abi.encodePacked(message.sender) to sender: abi.encode(message.sender) in src/ccip/CCIPLocalSimulatorFork.sol to enforce standard 32-byte ABI encoding with left-zero padding.

Testing

• Verified that CCIPLocalSimulatorUnitTest and CCIPLocalSimulatorForkRoutingTest pass locally without breaking existing routing logic.
• Ensures 32-byte compatibility for downstream receiver decoding.

[Yurii3721]

Thank you for looking into this. I am not the maintainer, but, based on the repo’s conventions, there are a few things before this commit can be merged.

The release playbook states that fixes are pushed to develop, whilst main receives updates from it.

It makes sense to add a regression test: verify that sender in a v1.6 message are a 32-byte word decoded into address. CCIPLocalSimulatorForkRouting.t.sol shows harness/mock templates.
Also, worth adding lastSender to MinimalStringReceiver and the check in test_routerDirectSend_routesWhenMultipleOffRampsShareSourceSelector. However, Sepolia->Arb Sepolia seems to be on CCIP 2.0 already. Maybe pin the block until for now? The simulator does not support OnRamp 2, I suppose it will be updated later by the maintainers.
Besides, the tests mentioned in the PR description are unaffected by this change as they do not go through _executePostV1dot6.

And add an entry to the ### Fixed section of the changelog (given the format for 0.2.9). The version bump is likely handled by the maintainers.

[andrejrakic]

Hello @Yurii3721 , thanks for raising the issue, using Chainlink Local and apologies for inconvenience. @Nalon is owning this fix and we will cut the new release as soon as possible.

@kurogami-ibrahim79 thank you for opening this PR and willingness to contribute to Chainlink Local. @Yurii3721 is right, we can not merge this to the main branch directly, there is a process of merging to develop, cutting a beta release, testing and then finally merging to main and cutting a stable release. More details here and here.

@Nalon can you please assist with this PR and make sure this is very well tested? Thanks in advance!