[Bug]: bk build list silently ignores the org in -p <org>/<pipeline> and queries selected_org #961

What happened?

For an account with two organizations, bk build list silently discards the organization
part of -p <org>/<pipeline> and queries whatever bk config get selected_org holds.

With selected_org=org-b:

$ bk build list -p org-a/widgets --limit 1 --summary --no-pager
Error: failed to list builds: GET https://api.buildkite.com/v2/organizations/org-b/pipelines/widgets/builds?...: 404 No pipeline found

The request went to org-b even though org-a was named explicitly. That case at least
errors, because the pipeline only exists in org-a.

The damaging case is a pipeline slug that exists in both organizations (api, infra,
deploy — common names). Then there is no error at all: the command returns a complete,
plausible list of builds belonging to the organization you did not ask for, with the
pipeline name you did ask for. Nothing in the default output announces the mismatch unless
you happen to read the organization field or the host path in web_url.

Related, and inconsistent between subcommands:

So bk build view builds the right URL with the wrong token, and bk build list builds the
wrong URL. Only pipeline list handles it correctly, and --org is not a global flag —
bk build list does not accept it at all.

Why this matters beyond ergonomics

For agent-driven use (this is increasingly the consumer — --agent, --summary, and the MCP
server all point that way) a wrong answer that reads as correct is worse than a failure. An
agent asked to check org-a's build has no signal that it was handed org-b's. For anyone whose
two organizations are separate clients or customers, that is a confidentiality problem, not
just a wasted query.

Expected behaviour

Any of these would resolve it, roughly in order of preference:

1. Honour the organization in -p <org>/<pipeline> consistently across subcommands, resolving
   the matching stored credentials rather than selected_org's.
2. Accept --org as a global flag with the same semantics, since bk pipeline list already
   implements exactly this.
3. At minimum, fail loudly: if -p names an organization that differs from selected_org,
   error instead of silently substituting.

Silently substituting a different organization is the one behaviour that should not survive.

Version

bk version 3.55.0, macOS arm64, installed via the buildkite/buildkite tap.