Clear the candidate build marker on a failed attempt

[damilolaedwards]

Problem

executeCandidateBuild marked a (slot, parent-tuple) candidate as started
before attempting the build, but never cleared that marker when the build
failed - either the engine call itself or the payload transform step. A
single transient error permanently blocked any retry of that candidate for
the rest of the slot, including a legitimate CL-client attributes
redelivery for the exact same parent, which was silently dropped instead of
retried.

Fix

Both failure paths now clear the marker before returning, so a later
trigger for the same tuple gets a real attempt instead of being dropped.

Testing

TestExecuteCandidateBuild_RetriesAfterAFailedAttempt drives two build
attempts for the identical (slot, parent-tuple) through a deterministic
forced failure (an unknown-fork chain stub, so the fork-version lookup
errors before any engine/beacon call is needed) and asserts both fire a
build-failed event.

Confirmed it catches the regression: reverted just the production file, the
test failed with exactly the predicted message (second attempt silently
dropped), restored the fix, test passes.

go build, go vet, and go test -race ./pkg/... all pass (aside from a
pre-existing, unrelated failure in pkg/webui caused by the frontend not
being built in this checkout).