Message Index re-conciliation should also fill in missing messages from the cannonical chain

Checklist

[X] This is not brainstorming ideas. If you have an idea you'd like to discuss, please open a new discussion on the lotus forum and select the category as Ideas.
[X] I have a specific, actionable, and well motivated feature request to propose.

Lotus component

[X] lotus daemon - chain sync
[ ] lotus fvm/fevm - Lotus FVM and FEVM interactions
[ ] lotus miner/worker - sealing
[ ] lotus miner - proving(WindowPoSt/WinningPoSt)
[ ] lotus JSON-RPC API
[ ] lotus message management (mpool)
[ ] Other

What is the motivation behind this feature request? Is your feature request related to a problem? Please describe.

On startup, the message index currently performs a "re-conciliation" process to clean up mesages that have been re-orged by walking back from the head of the cannonical chain upto the earliest epoch in the index and removing messages from all tipsets in the index that are not on the cannonical chain. This can be found here:

https://github.com/filecoin-project/lotus/blob/89f042e1a8e984b883790b952e0535b88e0dad5b/chain/index/msgindex.go#L104

However, it then directly starts syncing the message Index from the head of the cannonical chain without first filling in entries between the (last tipset in the index on the cannonical chain <> current head of the cannonical chain) which can cause missing entries in the Index unless they are manually backfilled. We should fix this.

See https://github.com/filecoin-project/lotus/blob/89f042e1a8e984b883790b952e0535b88e0dad5b/chain/index/msgindex.go#L133

Describe the solution you'd like

We should backfill messages in the index between (latest tipset in the index <> current head of cannonical chain) after re-conciliation is complete.

Describe alternatives you've considered

No response

Additional context

No response

filecoin-project / lotus