Summary

Mirrors the Start-loop's zero-guard at dequeueDuringBlockMovement so DoubleSpendWindow == 0 disables the queue filter consistently across both call sites. Closes a same-millisecond admission gap that only manifests under the default config.

The bug

The Start-loop dequeue at SubtreeProcessor.go:810-813 zero-guards the calculation:

validFromMillis := int64(0)
if stp.settings.BlockAssembly.DoubleSpendWindow > 0 {
    validFromMillis = stp.clock.Now().Add(-stp.settings.BlockAssembly.DoubleSpendWindow).UnixMilli()
}

dequeueDuringBlockMovement (pre-fix :3789) skipped that guard and ran the calculation unconditionally:

validFromMillis := stp.clock.Now().Add(-1 * stp.settings.BlockAssembly.DoubleSpendWindow).UnixMilli()

At DoubleSpendWindow == 0 that yields clock.Now().UnixMilli() (> 0), which trips the queue filter at queue.go:96 (validFromMillis > 0 && time >= validFromMillis) and rejects any batch enqueued in the same millisecond as the drain.

DoubleSpendWindow defaults to 0 (settings/blockassembly_settings.go:29). Under the default config, a block-movement drain could miss fresh batches that the Start loop would have admitted, leaving them queued for the next iteration. The fix is one zero-guard, mirroring the Start loop verbatim.

This was characterized in #841 and is the asymmetry called out in that PR's "Latent finding" section.

Test changes

• Test_zeroWindowAsymmetry → Test_zeroWindowFormulasAgree - renamed and flipped the drain subtest to assert admission. The test now pins post-fix parity between the two formulas.
• TestDequeueDuringBlockMovement_ZeroWindowAsymmetry → ...AdmitsSameMillisecond - flipped same_millisecond_batch_is_held_back to assert the batch drains. Kept the +1ms control subtest as a separate (now - window) cutoff smoke.
• TestDequeueDuringBlockMovement_RejectsChildOfConflictingParent - replaced the time.Sleep(5 * time.Millisecond) workaround with the clock seam (both stp.clock and stp.queue.clock pin to the same instant). With the fix, the batch admits at window=0 and the conflicting-parent rejection path is exercised deterministically. No more wall-time wait.

Test plan

• go vet ./services/blockassembly/... - clean
• go test -race -count=1 ./services/blockassembly/subtreeprocessor/ - pass (164s)
• go test -race -count=1 ./services/blockassembly/ - pass (101s)
• BenchmarkQueue sanity (control plane, not hot path): 154-193 ns/op, in line with previous runs.

Notes

• Production change: 5 added lines + 1 modified line in SubtreeProcessor.go, no API change, no new imports.
• The fix is on a control-plane path (only runs during block movement) so it does not affect the hot tx-batching path.
• Builds on test(blockassembly/subtreeprocessor): add clock seam for deterministic tests #841 (the clock seam) for test determinism; both characterization tests and the de-flaked race test use fixedClock to drive timestamps without time.Sleep.