fix: prevent second batch store reset wiping postage snapshot on --resync

[martinconic]

Checklist

• I have read the coding guide.
• My change requires a documentation update, and I have done it.
• I have added tests to cover my changes.
• I have filled out the description and linked the related issues.

Description

Fixes #5495: a node started with --resync while the postage snapshot is active shuts down during sync with:

get: get batch <id>: storage: not found

Root cause

The batch store is reset twice on startup in this configuration:

1. snapshotBatchSvc.Start() resets the store (resync) and rebuilds it from the snapshot, then sets postageSyncStart = maxBlockHeight.
2. The live batchSvc was constructed with the same o.Resync flag, so its Start() reset the store again, discarding the snapshot that was just loaded.

Live sync then started from the snapshot block height against an empty store, so the first top-up/dilute event referencing a batch created before the snapshot height failed with storage: not found, and the node shut down.

This matches the report exactly: two "resync requested, resetting batch store" log lines, and the fact that skip-postage-snapshot works around it (only one reset, and sync replays from contract genesis where every create precedes its top-up).

Note: this is independent of #5343/#5482. The flow originates in #5094 and is still present on master; the reporter's build (2.8.0-41d6efc6) predates the #5343 revert, but reverting #5343 does not address this.

Fix

The two reset sites are not redundant — one rebuilds from the snapshot, the other is the fallback rebuild for the no-snapshot / snapshot-failed / non-mainnet cases — they were just both armed at once.

Construct the live batch service after the snapshot path has run and pass resync only when the snapshot did not rebuild the store:

batchSvc, err = batchservice.New(..., o.Resync && !snapshotLoaded)

The reset logic stays in its single existing place (batchservice.Start()), exactly one service is armed to reset, and there is no runtime toggle. The store is still reset exactly once in every other case (snapshot skipped, failed, not applicable, or a non-resync start).

Testing

• TestResyncControlsReset in batchservice asserts both directions of the contract node.go relies on:
  • resync=true ⇒ store reset once
  • resync=false ⇒ store not reset (the post-snapshot live-service case)
• go test -race ./pkg/postage/batchservice/... passes
• go build ./pkg/node/... passes; go vet, gofumpt, and golangci-lint clean

Open API Spec Version Changes (if applicable)

None.

Related Issue

Closes #5495

AI Disclosure

• This PR contains code that has been generated by an LLM.
• I have reviewed the AI generated code thoroughly.
• I possess the technical expertise to responsibly review the code generated in this PR.

[acud]

to me the fact that there's two places where the batch service could get reset already smells a bit. with this change we have still two places where a reset happens + third path to disable one of them potentially. so the question is asked - why have two places that do this in the first place?

[martinconic]

The two reset sites aren't pure duplication. They serve different roles:

• snapshot service → resets + rebuilds from the snapshot
• live service → resets + rebuilds from chain genesis — this is the fallback path, needed when there's no snapshot
  So you can't simply delete one site without merging the two services (they use different listeners — snapshot filterer vs live chain backend).

I changed the implementation to not modify at all batchservice.go

[gacevicljubisa]

Suggestion: Instead of having this guard, we could expose batchservice.Reset(stateStore, batchStore) and just call it before start in case if --resync is set to true

[gacevicljubisa]

Additional solution could be to modify the Start interface:

Start(ctx context.Context, listener Listener, startBlock uint64) error

where we would pass snapshotEventListener and eventListener respectfully, and then when resync is done, we could set it to false.

But this requires interface changes.

[gacevicljubisa]

@acud wdyt?

[acud]

I am not sure exposing Reset is needed. From my perspective consider this:

1. if you want to reset (the flag was set) - you start the batch service the snapshot. If you don't want to reset - snapshot it nil.
2. inside the constructor, it detects - if the snapshot is not nil - reset, replay events, then continue startup normally, returning the instance.

If it is really needed to be able to reset without a snapshot, i.e. force a reset that reads directly from the blockchain, pass both a flag and the snapshot (nullable). Not sure I see the need for external callers to be able to reset the state of that component in that way.