feat(rest): add task signal endpoints

[nthmost-orkes]

What

Adds the two task signal endpoints that the Go SDK / conductor CLI already call but OSS never implemented:

POST /api/tasks/{workflowId}/{status}/signal        # async, returns 200
POST /api/tasks/{workflowId}/{status}/signal/sync   # sync, returns SignalResponse

"Signal" finds the first non-terminal WAIT task in the workflow (descending into running sub-workflows) and applies the given status + output to it — letting a caller complete a workflow's currently-blocked task without knowing its task reference name.

Why

Fixes #1197 (item 2). The Go SDK's SignalAsync posts to /api/tasks/{workflowId}/{status}/signal. OSS had no such route, so Spring fell through to the all-variable update route /{workflowId}/{taskRefName}/{status} and tried to coerce the literal "signal" into TaskResult.Status:

workflowId = <id>, taskRefName = COMPLETED, status = "signal"   →  MethodArgumentTypeMismatchException

Adding the literal /signal segment makes that pattern strictly more specific than the all-variable one, so Spring routes to it first. A MockMvc test using PathPatternParser (the production matcher) asserts POST /api/tasks/wf123/COMPLETED/signal resolves to the signal handler and not the update handler, locking the fix in.

User impact: A first-time user running conductor task signal --workflow-id <id> --status COMPLETED ... against an OSS server got an opaque 500 (MethodArgumentTypeMismatchException) because the request was silently matching the wrong endpoint. Now the signal reaches the workflow's waiting task as intended.

Design

• Service layer (TaskService.signalTask): the find-the-blocked-task-and-update logic lives in the service, mirroring Orkes' OrkesTaskServiceImpl.updatePendingTask / getPendingTasksForWorkflow.
• Sync response: the sync endpoint waits for the workflow to settle into its next blocking/terminal state and renders a SignalResponse per returnStrategy — the same poll-to-response mechanism the existing executeWorkflow endpoint uses. That logic (the Flux poll + recursive blocking-task discovery + NotificationResult assembly) was duplicated inline in WorkflowResource; this PR extracts it into a shared WorkflowSignalResponder and points both executeWorkflow and the new sync-signal endpoint at it.

Orkes parity

Source-of-truth Orkes files mirrored here:

• io.orkes.conductor.server.rest.TaskResource#signalWorkflowTaskASync / #signalWorkflowTaskSync — endpoint paths /{workflowId}/{status}/signal[/sync], returnStrategy (default TARGET_WORKFLOW) and timeoutMillis (default 5000) params.
• io.orkes.conductor.server.service.OrkesTaskServiceImpl#updatePendingTask / #getPendingTasksForWorkflow — "signal = update the first non-terminal blocking task, recursing into sub-workflows."

OSS-side additions (no Orkes parallel)

• WorkflowSignalResponder — OSS reaches the post-signal blocking state by polling (Flux.interval), whereas Orkes uses an enterprise WorkflowExecutionMonitor notification mechanism. OSS already chose polling for executeWorkflow; this just shares it. The Orkes-only collaborators (OrkesRequestContext/orgId, OrkesAuthentication permission checks, OrkesWorkflowExecutor) are multi-tenancy/enterprise and intentionally omitted.

Tests

• TaskServiceTest: signalTask found / not-found.
• TaskResourceTest: async, sync (StepVerifier), sync not-found (404), and the route-resolution regression test.
• Refactor safety: all 37 existing executeWorkflow/WorkflowResourceTest cases stay green; full conductor-rest suite passes.

[mp-orkes]

• How do we know this works end-to-end? The tests are almost a tautology. Completely mocked like testSignalTask.
• Orkes (the source-of-truth per the description) has E2E signal tests. We need equivalent coverage here.
• signalTimeout is missing from SignalResponse. Orkes sets it on timeout; without it, a timed-out signal looks identical to a successful one.

[nthmost-orkes]

• How do we know this works end-to-end? The tests are almost a tautology. Completely mocked like testSignalTask.

Thanks for calling that out!

• Orkes (the source-of-truth per the description) has E2E signal tests. We need equivalent coverage here.

Agreed.

• signalTimeout is missing from SignalResponse. Orkes sets it on timeout; without it, a timed-out signal looks identical to a successful one.

Thanks, will fix

[nthmost-orkes]

Thanks for the review, @mp-orkes. Two changes in the latest commit:

signalTimeout field — Added to SignalResponse (matching Orkes), propagated through NotificationResult.toResponse() to both WorkflowRun and TaskRun, and set to true in WorkflowSignalResponder's timeout fallback path. Three new unit tests in NotificationResultTest cover propagation to WorkflowRun, propagation to TaskRun, and the false-by-default case.

E2E integration tests — Added SignalTaskSpec to the test-harness. It runs against a real Redis testcontainer (same setup as every other spec in that module) and exercises TaskService.signalTask() without mocking:

1. Signal completes a WAIT task and the workflow advances
2. Signal with no blocking task returns null
3. Signal on a non-existent workflow returns null
4. Signal descends into a sub-workflow to complete its blocked WAIT task

These cover the four paths in TaskServiceImpl.findPendingBlockingTask() against a real backing store.