fix: stabilize flaky snapshot bootstrapping tests

[LautaroPetaccio]

stabilizes test/integration/syncronization/bootstrapping.spec.ts, a pre-existing flaky sync suite. surfaced while validating catalyst#1952 (a bootstrapping test failed in its ci) but unrelated to that bump — the suite stubs the validator.

root cause

each test asserts on server2's synced state immediately after startProgramAndWaitUntilBootstrapFinishes, but bootstrap keeps settling after that signal: under ci load a transient inter-server fetch (ENOENT / fetch failed) makes the first bootstrap attempt fail and schedules a retry. so the assertions read incomplete state, and which test trips varies per run (which is why patching one assertion just moved the failure to a sibling).

fix

• poll every post-bootstrap "settled-state" assertion — processed snapshots, reported deployments, persisted failed deployments — via the existing awaitUntil helper (20s window, well within the 120s integration timeout) instead of reading once, so the bootstrap retry has time to complete.
• replace the exact markSnapshotAsProcessed call-count assertions (toBeCalledTimes(3) / (2)) with distinct-set-of-marked-hashes checks. the test mocks snapshotStorage.has → false, so a bootstrap retry re-marks the same snapshots and the call count varies across runs; the distinct set of marked hashes does not. asserting the set preserves the "exactly these snapshots processed, nothing extra" intent while tolerating retries.

verification

ran the suite repeatedly locally — green. before the fix it failed ~1 in 2 (either an early-read on a state assertion, or the count assertion polling out at 20s because a retry pushed the count past the expected value).

no production code touched; test-only.

[decentraland-bot]

Thanks for stabilizing this suite. I found one reliability issue that should be addressed before merge.

Findings

• P1: The new set-based spy assertions can pass as soon as every expected hash has been observed once, but they do not prove the bootstrap retry work has settled before the spy is reset and reused for the second sync phase. Since the PR explains that transient bootstrap fetch failures can schedule retry work after the bootstrap-finished signal, late calls from the first phase can either contaminate the second phase after mockReset() or let the test move forward before the condition it is trying to stabilize is actually drained. Please wait on a real settled/idle condition for the bootstrap retry work before resetting the spy, or assert durable DB/deployment state for the phase instead of reusing this spy across unsettled async work.

Security review: no security issues found; this is test-only.

CI: validations/title/quay passed; test-content is still pending.

---

Reviewed by Jarvis 🤖 · Requested by Lautaro Petaccio (<@U025WCHLMN3>) via Slack