[pradyb]

What / why

workflow approve --watch only reported gate decisions and the final conclusion, so users had to run workflow view --watch in a second terminal to see what the run was doing between gates. It now streams job/step progress inline with the gate events.

Behaviour

• Text: one line per job/step start and completion, interleaved with gate prompts/decisions. Step lines carry the job name (Build / compile) so parallel jobs stay unambiguous.
• --json: NDJSON gains job_started, job_completed, step_started, step_completed (same shape as view --watch --json), plus a leading {"kind":"watch_started","run_id":N} so scripts learn which run was resolved when --run is omitted. Consumers that assumed only gate/run_done kinds should ignore unknown kinds (CHANGELOG notes this under Changed).
• Reuses viewWatchState.diff from view --watch; costs one extra API call (list jobs) per poll. A failed jobs fetch is logged at debug and never stops the watch; the next successful poll catches up because diff tracks state, not polls.
• Not a full-screen TUI like view --watch: the per-gate confirmation prompt needs stdin.

Fixes (found along the way)

• Without --run, the "Watching … run N" header and the confirmation prompt printed run 0; they now show the resolved run.
• The shared diff emitted a job's job_completed before its own steps when the whole job finished between two polls. Now steps come first. This also changes the order within one poll for view --watch --json (CHANGELOG under Fixed).

Docs

docs/commands.md (bullet, flags table, new two-gate watch example with sample output), docs/examples.md, approve --help text, CHANGELOG (Changed + Fixed). Verified against --help of a freshly built binary.

Testing

• New tests: progress events around gates (exact order), jobs-fetch failure doesn't stop the watch and catches up, watch_started carries the resolved run ID, cmd-level text output and resolved run ID in header + prompt, diff ordering (fails without the fix). Updated existing tests for the new watch_started event.
• gofmt -l . clean, go mod verify, go build ./..., go vet ./..., ./scripts/check-coverage.sh → 93.7%.
• Live against prady-github-api/public-repo (two-approval.yml, target=dev dry_run=true):
  • run 37882429788: text mode with --run, --yes -e approval-1 -e approval-2 → both gates approved, progress shown, success, exit 0 (this run surfaced the ordering bug above).
  • run 37882529895: --json, no --run → resolved run reported in watch_started, clean NDJSON, empty stderr, exit 0.
• Not verified live: the interactive (no --yes) prompt path, which needs a TTY (covered by unit tests). *_started events weren't observed live because the demo's jobs finish within one 5s poll (covered by unit tests).

Closes #67