Correctly surface errors when requesting data from future blocks

The deployed networks have been supporting follower nodes for a while. Follower nodes are eventually consistent and can get behind the actual sequencer. This can cause clients to request data from future blocks from the perspective of the node it is reaching.

From the perspective of `rust-sdk`, we should make sure we correctly surface these errors and ideally separate them from "incorrect range" errors which is what (I think) we are surfacing now. Note that this might require changes from the node, as we base the error variants on the app-level error codes that the node returns. In any case, in the meantime, we can also decide to match on substrings until the node more clearly communicates this type of errors.

This is not currently fatal because:

- client users can _already_ detect this error (even if by substring matching), but we can make the experience better here
- retrying immediately is harmless and this problem happens very infrequently

Untersuchen Sie den Fehlerbehandlungscode im SDK, der Antworten vom Node verarbeitet, wahrscheinlich in einem Client- oder Netzwerkmodul. Identifizieren Sie, wo derzeit 'incorrect range'-Fehler gemappt werden. Untersuchen Sie die App-Level-Fehlercodes oder Antwortstrukturen des Nodes, um zu sehen, ob Fehler für zukünftige Blöcke unterschieden werden. Schreiben Sie einen Test, der eine Anfrage für Daten aus einem zukünftigen Block simuliert, um zu überprüfen, ob die neue Fehlervariante korrekt an die Oberfläche gebracht wird.

Vom Indexierungsmodell aus dem Issue-Text verfasst.