Research if we can drop backwards compatibility

[DylanVerstraete]

See if we can read the entire chain storage when we start the graphql to be able to drop all objects and events that were emitted in the past.

[sameh-farouk]

Closing as won't-fix. The original motivation was to avoid maintaining version-specific event handlers for historical spec versions, but:

1. The backwards compatibility pain is solved. PR feat: automate type generation with append-only version log #207 automated type generation — all historical versions (v9 through v157) are handled correctly with zero manual maintenance. Adding a new spec version is a single make typegen-add command.

2. Reading storage state would lose history. The GraphQL serves historical data — contract bill reports, uptime events, NRU consumption, power state changes, creation timestamps, deleted entities. A storage snapshot only gives current state.

3. Subsquid's processor model is event-driven by design. A storage bootstrap would require custom infrastructure outside the framework, adding complexity instead of reducing it.

4. The migration to Hero Ledger makes this moot. TFChain is being superseded. Investing in a fundamentally different indexing strategy for a system being phased out doesn't make sense.

5. The zero comments since March 2023 confirms nobody has needed this.