Error retries seem to lose the Firehose cursor

We're seeing logs like this one frequently:

WARN Firehose selected first streamed block's parent should match subgraph start block, reverting to last know final chain segment,
firehose_start_block: #18746373 (5ca99c16915d2cd025e4fc1b3962c08eb75d171840d70116d2ff9204d3a1c5cc), subgraph_current_block: #18746373 (ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff)

The subgraph will then revert by exactly 200 blocks which is a hardcoded value in FirehoseMapper::final_block_ptr_for.

I think this reproduces when a subgraph retries a deterministic error, so it may be that we're losing the current block hash in this retry process. Given that those retries happen frequently and reverting makes the retry process more expensive, it would be good to look into how we can avoid this situation.

Beginne damit, die Behandlung von Retries bei deterministischen Fehlern nachzuverfolgen und zu untersuchen, wie der aktuelle Block-Hash FirehoseMapper::final_block_ptr_for erreicht. Reproduziere nach Möglichkeit die protokollierte Firehose-Cursor-Diskrepanz und verifiziere, dass Retries den Cursor beibehalten, anstatt den fest codierten Revert um 200 Blöcke auszulösen.