deploy-statuslisted

# Checking a pipeline Two rules first: - **CI connections are their own name space.** Call `list_ci_connections` first; those names are the only valid `connectionName` values. A *server* name will not resolve here and a connection name will not resolve as a `serverName` — they are different lists of different things. - **The CI tools are the only route to a CI server.** A shell on a host that happens to reach Jenkins over the network is not an alternative, and curling the provider's API to get around a denied tool is the same act as expressing a denied file rule as a shell command. If `trigger_run` is denied, it is denied. ## Order to work in 1. `list_ci_connections` → `list_pipelines` → `list_runs`. Status, timing, branch and actor, newest first. 2. `get_run` — normalized status plus the **per-step outcomes**. This names the failing step, which is the actual question most of the time. 3. `get_run_logs` — **last**. The logs are large and the three calls above usually answer it. ## Starting, cancelling, re-running `trigger_run` is asked for **every time**, on every access group, including one raised to allow — it is never remembered from an earlier approval. OpsMaxx cannot read the pipeline definition before it starts and cannot see what it deploys or where, so the approval is the only control point. Say what you expect the run to do before requesting it. `rerun_run` is **GitHub only**. `cancel_run` asks the provider to stop a run already going. ## Buil