fix(server): recheck inclusion instead of re-broadcasting on watch stop

[valentinfernandez1]

What

A chainHead_follow stop aborts subxt's transaction watch without saying anything about the transaction itself, which may already be on chain.

Before, Preimage.submit treated this like any other uncertain watch failure: retry once by re-signing and re-broadcasting. If the first transaction had actually landed, that stored the preimage twice and burned allowance for nothing; if the retry also errored, the call failed even though the submission had succeeded.

Now, when the watch dies without a verdict, the extrinsic is looked up in the next few finalized blocks first. Found on chain: its dispatch outcome is taken from the block events and nothing is re-broadcast. Not found: the old single-retry behavior applies unchanged. Definitive node verdicts (invalid, dropped) skip the re-check entirely.

[pgherveou]

Question: instead of re-signing and re-submitting. why not re-trying the already signed tx?
useful AI comment when I pointed it in that direction:

build/sign
→ submit
→ watch interrupted
→ scan for original hash
→ if absent, re-submit identical signed bytes
→ never re-sign with a new nonce while the original outcome is unknown

Only rebuild after proving the original expired or was never included and its nonce remains unused.

Can you comment on whether it make sense or not

[valentinfernandez1]

Question: instead of re-signing and re-submitting. why not re-trying the already signed tx? useful AI comment when I pointed it in that direction:

build/sign → submit → watch interrupted → scan for original hash → if absent, re-submit identical signed bytes → never re-sign with a new nonce while the original outcome is unknown

Only rebuild after proving the original expired or was never included and its nonce remains unused.

Can you comment on whether it make sense or not

Yes, I avoided it as it was a bigger refactoring on the logic as we need better detection logic. For example if the first transaction is successful the identical re submit will be rejected with something like nonce already used, that rejection isn't an actual error but rather a signal that the first transaction actually landed, so it needs to be remapped instead of surfacing as a hard error.

I can work on implementing this and couple it with this PR or we can just merge this and do it as a follow up, whatever you prefer