feat(task): support parameters on task run

[skipi]

Summary

Make sem-ai's parameterized API calls work. Two related changes to how the CLI passes parameters:

1. task run — support parameters at all (they were silently dropped).
2. pipeline promote — fix --param, which sent the wrong body shape and returned HTTP 500.

The two endpoints consume parameters differently, so each path is matched to its endpoint (see note below).

1. task run: support --param, --branch, --pipeline-file

sem-ai task run <id> posted run_now with a nil body, so task parameters were silently dropped — parameterized scheduled tasks couldn't be triggered from the CLI at all.

Adds to task run:

• --param KEY=VALUE (repeatable)
• --branch — git ref the task pipeline runs on
• --pipeline-file — pipeline YAML the task runs

The body is built only when an override is supplied, so the parameter-less default is unchanged.

Shape: run_now consumes parameters as a map, with branch / pipeline_file alongside.

2. pipeline promote: fix --param (was HTTP 500)

pipeline promote --param sent parameters nested as "parameters": [{name, value}]. But the POST /promotions endpoint maps every non-reserved top-level body key — everything except switch_id/name/user_id/override/request_token/pipeline_id — to a promotion env var whose value must be a string. The nested array left parameters as a list-valued env var, so the server rejected it (EnvVariable value invalid) and returned HTTP 500.

Fix: send each --param as a flat top-level body key.

Why the two paths differ: run_now consumes parameters as a map; /promotions consumes flat top-level keys. Intentional per-endpoint contract — each is now correct.

Verified

• task run with --param / --branch / --pipeline-file → triggers a parameterized task: 200 { "workflow_id": "…" }.
• pipeline promote <id> --target "<promotion>" --param KEY=VALUE --confirm → 200, promotion triggered.

go vet + go test ./cmd/ pass; gofmt clean.

🤖 Generated with Claude Code