refactor: remove generic T from WorldChainNode

[Dzejkop]

Hardcode FlashblocksContext as the only context type for WorldChainNode, eliminating unnecessary generics throughout the codebase.

• Replace WorldChainNode with concrete WorldChainNode
• Simplify WorldChainNodeContext trait to WorldChainNodeTypes
• Remove WorldChainTestContextBounds and WorldChainNodeTestBounds traits
• Clean up turbofish annotations in tests and main.rs

This removes ~340 lines of complex trait bounds and type gymnastics while maintaining the same functionality.

🤖 Generated with Claude Code

[0xOsiris]

I will just explain the rationale here:

The reason this was initially created is because in the current testing infrastructure, and node binary the Evm, Network, PayloadServiceBuilder, and ComponentsBuilder are all completely interchangeable.

Why is this important?

When you are in the experimental development phase of certain components it's much more efficient to create new types rather than change the runtime configuration of already stable types (and potentially make them unstable). You can use stable types to test the experimental types with assertions over a generic context. We did this a lot when testing the flashblocks payload builder vs the standard payload builder for block parity before enshrining the runtime configuration. Imo this was very beneficial, and I imagine will be beneficial in the future with large features. Experimental component types only get "enshrined" at runtime in cannonical contexts when they are ready. But during testing they are deployable in complete isolation.

Think Parallel EVM, Experimentally enshrined precompiles, different database architectures etc.

I personally don't see any reason to make our testing infrastructure, and components builder less flexible to quick customization just because of verbosity. This will just imo slow down future development efforts, and we will probably end up just rebuilding the same thing when we already have robust testing infrastructure in place over completely generic configuration of node components.

[0xForerunner]

I will just explain the rationale here

I'm not entirely sure I agree with this, I kinda prefer losing 400 line of code :p

[alessandromazza98]

I'm commenting here to leave my take here too (I wrote a message on slack but it's better to have it here):

I see the advantages Leyton is pointing out but I still think it's a bit net negative because it makes the code much harder to read and reason about. By the way I'm not in a rush to remove it now if we don't want to do it now. We could keep it for now and see if we use this generic in the future and it's really helpful or not.