conductor workflow start --sync is broken on OSS: calls Orkes-only /workflow/execute endpoint

[nthmost-orkes]

Problem

`conductor workflow start --sync` silently fails on OSS Conductor with a 404.

The CLI implements `--sync` by calling `POST /workflow/execute/{name}/{version}` (via the Go SDK's `ExecuteWorkflow`). This endpoint does not exist in OSS Conductor — it is an Orkes Conductor-only API.

On an OSS server the call returns a 404, which the CLI surfaces as a generic API error rather than a helpful message.

Expected behavior

`--sync` should work on OSS Conductor. It should:

1. Start the workflow asynchronously (via `POST /api/workflow/{name}`)
2. Poll `GET /api/workflow/{id}` until the workflow reaches a terminal state (COMPLETED, FAILED, TERMINATED, TIMED_OUT)
3. Print the workflow output

Fix

Implement polling fallback in `conductor-oss/conductor-cli`:

• Try `ExecuteWorkflow` (Orkes path) first
• On 404, fall back to start-async + poll loop
• Or: always use the poll approach for OSS compatibility

The Go SDK's `WorkflowExecutor.MonitorExecution` provides a channel-based polling primitive that could be used here.

Affects

• `conductor-oss/conductor-cli` cmd/workflow.go `startWorkflow`

[v1r3n]

This is already available in OSS after the recent releases.