fix: check for existing buildkitd before mounting sticky disk

[pbardea]

When setup-docker-builder is invoked twice in the same job (e.g. via a composite action called twice), the second invocation was calling setupStickyDisk() before detecting the already-running buildkitd. This caused a new sticky disk to be mounted on top of /var/lib/buildkit while buildkitd was still running with in-memory metadata referencing snapshot directories from the original disk. The subsequent build then failed with:

ERROR: failed to solve: failed to read dockerfile: failed to walk:
resolve: lstat /var/lib/buildkit/runc-overlayfs/snapshots/snapshots/N:
no such file or directory

Fix: move the buildkitd process check to the very beginning of startBlacksmithBuilder(), before any sticky disk setup. If buildkitd is already running, log an informational message and return immediately so the fallback path reuses the existing configured builder (from the first invocation) without corrupting its overlayfs snapshot state.

Based on #65 by @chadxz, with dist rebuilt.

---

Note

Medium Risk
Changes builder initialization control flow to early-exit when buildkitd is detected, which impacts how the action behaves when invoked multiple times in a job and could affect reuse/fallback behavior.

Overview
Prevents double-initialization of the Blacksmith builder by checking for an existing buildkitd process at the start of startBlacksmithBuilder() and returning early if one is found, avoiding remounting the sticky disk over a live /var/lib/buildkit.

Updates tests/mocks to account for the new pgrep buildkitd call so repeated invocations reuse the already-configured builder instead of corrupting BuildKit state.

^{Written by Cursor Bugbot for commit debddcb. This will update automatically on new commits. Configure here.}