Resume workflow call - add lock and idempotency

[adonthi-fws]

Pull Request type

• Bugfix
• Feature
• Refactoring (no functional changes, no api changes)
• Build related changes
• WHOSUSING.md
• Other (please describe):

NOTE: Please remember to run ./gradlew spotlessApply to fix any format violations.
Done

Changes in this PR

resumeWorkflow had no lock and no "already in target state" check, unlike pauseWorkflow right above it. If two resume calls raced on the same execution, the loser would read a status that had already moved to RUNNING and throw IllegalStateException → 500, even though the workflow was already resumed correctly. Seen in production: a resume call got a 500 while the same execution's tasks ran fine ~40s later via the background sweep.

Changes:

1. WorkflowExecutorOps.resumeWorkflow now takes executionLockService's lock around the read-check-write, same as pauseWorkflow.
2. If the workflow is already RUNNING, resume returns as a no-op success instead of throwing. Genuine bad states (terminal, never started) still throw IllegalStateException — unchanged.
3. TestWorkflowExecutor.testResumeWorkflow updated to mock the lock and added a case for the already-RUNNING no-op.

Issue #1665

Testing:

1. Tested by making a resume call on a running workflow
2. Tested by making 2 race calls on a paused workflow

[adonthi-fws]

@v1r3n @nthmost
please review this

[nthmost-orkes]

Approving. Double-checked the downstream consumers -- no changes needed in the SDKs (Python/JS/Java/C# resume calls are all thin void-returning wrappers with no status-code special-casing) or in the UI (single-action Resume only surfaces on PAUSED; bulk correctly buckets already-running as success). Nice parity with pauseWorkflow.