refactor(floresta-chain): apply strict error handling in flat_chain_store

[Vedd-Patel]

Description and Notes

related issue: #1053

This PR improves systematic error handling in flat_chain_store.rs, focusing on clearer error semantics and correct propagation paths

what changed

• reworked chainstore error modeling to use ChainstoreError with clearer variants and messages
• preserved error sources for internal failures via Internal(Box<dyn Error + Send + Sync>)
• improved index/probing error behavior so not-found/full-index paths are handled correctly
• added explicit propagation for InvalidValidationIndex in save_roots_for_block
• kept module-level strict clippy guards for error-handling pattern

Contributor Checklist

• I've followed the contribution guidelines
• I've verified one of the following:
  • Ran just pcc (recommended but slower)
  • Ran just lint-features '-- -D warnings' && cargo test --release
  • Confirmed CI passed on my fork
• I've linked any related issue(s) in the sections above

[Vedd-Patel]

@moisesPompilio you can also take a look!
I would love your feedbacks if any

[Davidson-Souza]

A few architectural questions.

It also looks like there was a regression with how we handle dirs.

[jaoleal]

It would be interesting if you could split the changes, itll be easier to review

[Vedd-Patel]

It would be interesting if you could split the changes, itll be easier to review

from next time i'll keep this in mind

[jaoleal]

Guys, the only recoverable error inside the flatchainstore is HeadersNotFound... Should we review the plan ?

@Davidson-Souza

[Davidson-Souza]

Guys, the only recoverable error inside the flatchainstore is HeadersNotFound

That's not true. OversizedAccumulator, CorruptedDatabase and InvalidValidationIndex are fixed by a reindex.

[lorenzolfm]

Hi @Vedd-Patel. Thanks for your work on this. Your PR is going on the right direction :)

I've made some comments about simplifying the Internal variant, the value of some tests you added and notes about some changes that you may want to avoid to keep this PR on track with your goal and keep it easy for contributors to review.

[lorenzolfm]

Addressed some comments. By the way there are still some renames on variable names that I think you should avoid doing. The smaller the diff, the higher the quality of reviews you'll get :)