EPMDEDP-17360: feat: Add pipelinerun get --wait and pipeline results

[geekhubuser]

Description

An AI agent with the krci skills plugin and krci v0.16.0, with kubectl denied, ran "build main and tell me the version and quality result" on a local testbed. It got there, but in 41 turns: it polled pipelinerun get more than 15 times, read the built version from a task log, distrusted a passing Sonar gate, and on an older portal could not tell why project build failed. This PR closes those four gaps in the CLI; no portal change.

• krci pipelinerun get --wait polls the run every 10 s until it finishes, then prints it the way get does, including --reason and --logs. The exit code is 0 only for Succeeded; any other final status still prints the run and exits 1 with pipeline run "<name>" finished with status <status> and a --reason hint. --timeout (default 1h) bounds the wait. Waiting lives on get, not on project build, so it covers every run type, including the review and build runs that git events start.
• krci pipelinerun get and list carry the run's pipeline results (status.results): results in JSON and a Results: block in the table, for example VCS_TAG, the version a build produced. Only a run still in the cluster has them: Tekton Results summaries do not, and the portal has no REST route for the stored PipelineRun record. --wait returns while the run is still in the cluster.
• krci project build against a portal without POST /rest/v1/pipelineruns/build (every portal release up to 0.8.0) printed json: cannot unmarshal string into Go struct field ErrorNOTFOUND.error. The generated client parses a JSON 404 into the tRPC error envelope before checkBuildResponse runs, so the existing route-missing mapping, and the "Portal too old" row of docs/project.md, were never reached. Build now reads the raw response; the message is portal has no endpoint for this command (Route POST:/rest/v1/pipelineruns/build not found); upgrade the portal.
• krci sonar gate printed (no conditions — project has no analyses yet) for any gate without conditions, including a passed gate right after an analysis. Only status NONE says that now; a gate with a status prints (no conditions evaluated).

Fixes EPMDEDP-17360

Type of change

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Enhancement (non-breaking change which improves an existing feature or documentation)
• Breaking change (fix or feature that would cause existing functionality not to work as expected)

results is an added JSON field. Without --wait, get behaves as before, including exit 0 for a failed run.

How Has This Been Tested?

Unit tests came first. The new project build test reproduced the exact error from the discovery run before the fix. make ci in golang:1.26 on a clean LF clone of the branch: golangci-lint 0 issues, go test -race ./... passes, build OK.

/e2e per e2e/runner.md, binary built from this branch, portal rows read-only against a live portal with the developer role: pipelinerun 67 PASS · 2 FAIL · 0 SKIP, project build 10 PASS · 0 FAIL · 3 SKIP.

Scope	Result
pipelinerun sections 1 to 9, deterministic harness	67/69 PASS
New rows PR-H-08, PR-V-12 to PR-V-14, PR-GE-08 to PR-GE-11, PR-J-05	9/9 PASS, one Haiku agent per row, same verdicts as the harness
project build PROJ-B-01 to PROJ-B-10, dry-run and not-found rows included	10/10 PASS

• FAIL PR-A-01 and PR-A-02 (auth gating) are not from this PR: the binary built from main 12bee91 gives the same output. The rows expect authentication required, the CLI prints not authenticated: run 'krci auth login'.
• SKIP PROJ-B-11 has no not-ready branch to point at; PROJ-B-12 and PROJ-B-13 start a real build.
• PR-J-05 needs a build that is still in the cluster; it ran against the build from the last row of the next table.

Live, read-only:

Check	Result
project build my-app --dry-run -o json against a portal without the build route	main: calling project build: json: cannot unmarshal string into Go struct field ErrorNOTFOUND.error ...; this branch: portal has no endpoint for this command (Route POST:/rest/v1/pipelineruns/build not found); upgrade the portal
pipelinerun get <finished run> --wait	returns at once (0.5 s, same as get); exit 0 for Succeeded, 1 plus the --reason hint for Failed
sonar gate for a project without an analysis	(no conditions — project has no analyses yet), unchanged; a passed gate with conditions prints the table as before
pipelinerun get <review run> --wait -o json, started while the run was Running	blocked 405 s and printed the result 5 s after the run ended (Failed, 8m 10s), exit 1 with the --reason hint
pipelinerun get <build run> --wait -o json, started while the build was Running	blocked 1061 s and printed the result 1 s after the build ended: Succeeded, exit 0, results.VCS_TAG = build/<version>; the table view shows Results: VCS_TAG=build/<version>, and krci project versions lists the same <version> as the newest version of that branch

The pipelinerun start rows were not run: they need the Pipelines from e2e/pipelinerun/fixtures/ applied to the cluster, and this PR does not touch start.

Checklist

• I have performed a self-review of my code
• I have commented on my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation
• My changes generate no new warnings
• I have added tests that prove my fix is effective or that my feature works
• New and existing unit tests pass locally with my changes
• Pull Request contains one commit. I squash my commits.

Screenshots (if appropriate)

N/A

Additional context

Docs: docs/pipelinerun.md (Results, Waiting for a run, JSON results), docs/project.md (build and wait), docs/sonar.md, README command tree and agent scenario. e2e: e2e/pipelinerun/test-cases.md gains PR-H-08, PR-V-12 to PR-V-14, PR-GE-08 to PR-GE-11, PR-J-05 and the SUCCEEDED_RUN_NAME and BUILD_RUN_NAME placeholders.

The same discovery found gaps this PR leaves out, each a separate ticket: a deploy verb (the deploy run is assembled in the portal UI), filtering deploy runs by environment, and pod logs and events (need a portal REST route first).