builder: Do not fail if we have a stale lock.

[mathieu-plak]

• If we find a stale lock and kick it out, we need to continue the loop not fallthrough.

[mathieu-plak]

@claude review

[claude]

LGTM — straightforward control-flow fix; the missing continue would have caused stale-lock cleanup to fall through into the exclusive-lock check using the just-deleted lock.

Extended reasoning...

Overview

Single-line change in snapshot/builder.go adding a continue statement after a stale lock is successfully deleted in the Builder.Lock() lock-acquisition loop. Without it, execution falls through to the subsequent if lock.Exclusive check using the stale lock object that was just removed, which could spuriously abort lock acquisition.

Security risks

None. The change does not affect authentication, crypto, or permissions — it only corrects a control-flow bug in stale lock reclamation. If anything, this slightly improves correctness around lock handling rather than introducing risk.

Level of scrutiny

Low. This is a one-line, mechanical fix to a clear logic bug — the bug is self-evident from reading the loop body, and the fix is the obvious correct shape (skip remaining checks for the lock you just deleted, proceed to the next iteration).

Other factors

PR description matches the code change exactly. No bugs reported by the bug hunting system. The author (mathieu-plak) explicitly requested review. The change is small, self-contained, and follows the established pattern within the same function.