fix: return error when lock acquisition fails instead of nil

[raman1236]

Problem

When LockingExecutorWrapper.Plan(), Apply(), or Destroy() fail to acquire a lock (locked == false), they return a nil error. This causes the caller run() function in cli/pkg/digger/digger.go to silently succeed — the switch case falls through to the default return &execution.DiggerExecutorResult{}, "", nil, reporting success to CI even though no actual plan/apply/destroy was performed.

This means CI builds pass even when a lock could not be acquired, giving users a false sense that their infrastructure changes were processed.

Root Cause

In libs/execution/execution.go:

• Plan() returned nil, false, false, plan, "", nil when locked == false
• Apply() returned nil, false, "couldn't lock ", nil when locked == false
• Destroy() returned false, nil when locked == false

All three methods returned nil error on lock failure.

Fix

Return a descriptive fmt.Errorf("failed to acquire lock for project") error from all three methods when locked == false, so callers can detect and properly report the lock failure.

Tests

Added 4 new unit tests:

• TestLockFailurePlanReturnsError — verifies Plan returns error on lock failure
• TestLockFailureApplyReturnsError — verifies Apply returns error on lock failure
• TestLockFailureDestroyReturnsError — verifies Destroy returns error on lock failure
• TestLockSuccessDelegatesToExecutor — verifies all three methods delegate correctly when lock succeeds

All tests pass.

Fixes #1366

[raman1236]

Friendly ping — this PR fixes a bug where lock acquisition failures return nil instead of an error, which can lead to silent data races. Would appreciate a review when convenient. Thanks!