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

### What happened?

For an account with two organizations, `bk build list` silently discards the organization
part of `-p /` 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:

| Command | Organization actually queried |
|---|---|
| `bk build list -p /` | `selected_org` — org prefix discarded, no warning |
| `bk build view -p /` | The org in `-p`, but with `selected_org`'s credentials, so it fails `404 No organization found` |
| `bk pipeline list --org ` | Correct — org and credentials both resolve |

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 /` 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.

Start by comparing the organization and credential resolution used by `bk build list` and `bk build view` with the working `bk pipeline list --org` path. Trace how `-p /` is parsed and how `selected_org` is used; done means explicit organization selection is honored consistently, or a mismatch fails loudly, with tests covering separate and shared pipeline slugs.

Written by the indexing model from the issue text.