feat: reserve-expanding sync eligibility for redistribution game (SWIP-44)

[aloknerurkar]

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

Implements SWIP-44: Reserve-Expanding Sync Eligibility.

Currently, Bee excludes a node from participating in the redistribution game whenever any historical pullsync is active (SyncRate() > 0). When a node is expanding its reserve into a lower bin ($d-1$) in preparation for a storage radius decrease, this sync can take hours, causing the node to miss rounds despite maintaining a complete and valid reserve at the current storage depth $d$.

Because the reserve digest $H(R_N(d))$ is computed strictly over PO bins $p \geq d$, chunks arriving in bins $p < d$ are disjoint from the reserve and do not influence the digest. This PR amends the eligibility check to allow participation during sub-depth sync:

1. pkg/puller:
   • Added bin-level active historical sync worker tracking (activeHistSyncs [swarm.MaxBins]int, activeHistSyncsMu sync.RWMutex).
   • Exposed IsBinSyncing(bin uint8) bool and depth-aware IsReserveSynced(depth uint8) bool.
   • Updated mock syncer and added TestIsReserveSynced.
2. pkg/storageincentives:
   • Updated Agent constructor and sampling handler to evaluate reserveSyncedFunc(committedDepth) instead of blanket global sync state.
   • Added unit tests covering game participation during sub-depth sync vs. reserve-depth sync.
3. pkg/node:
   • Wired pullerService.IsReserveSynced(depth) into storageincentives.New.

Open API Spec Version Changes (if applicable)
N/A

Motivation and Context (Optional)
Addresses SWIP-44 (ethersphere/SWIPs#92).

Related Issue (Optional)

• Addresses SWIP-44: eligibility for sampling and game participation during reserve-expanding pull-sync  SWIPs#92

Screenshots (if appropriate):
N/A

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.

[sbackend123]

Nice job!

I would just clean up it a little bit - removing "formatting" changes, so PR looks bigger than it is.

[aloknerurkar]

Nice job!

I would just clean up it a little bit - removing "formatting" changes, so PR looks bigger than it is.

So this formatter is actually from our coding style doc. We used to follow it but I see now we dont.
https://github.com/ethersphere/bee/blob/master/CODINGSTYLE.md#code-formatting
https://github.com/ethersphere/bee/blob/master/Makefile#L74

I had my editor setup to run these formatters as soon as I open any file. I will revert the changes for now but we should update the coding style and makefile for others in future. I personally prefer this formatting as it breaks down std library, external and internal imports.

[martinconic]

When a node uses Capacity Doubling, it stores chunks locally at radius 8, but commits on the blockchain at depth 9. It is responsible for 2 adjacent "sister neighborhoods". The PR only checks if bins >= 9 are synced, completely ignoring bin 8. Is this right?

[aloknerurkar]

Did you check the SWIP?
I believe this is intentional and consistent with how the reserve digest itself is calculated.

CommittedDepth() (doublingFactor + StorageRadius()) is what the redistribution game and the sample are actually keyed on — see sample.go's own doc comment[L56-60]. With a physical radius of 8 and a doubling factor of 1, committed depth is 9, and ReserveSample only ever reads chunks at proximity ≥ 9 to the anchor — bin 8 chunks (which straddle both sister neighborhoods) simply aren't part of what gets hashed into the digest.