allow downloading artifacts in sibling pipelines

Currently, buildkite-agent covers the following use case for downloading artifacts.

:heavy_check_mark: a step inside pipeline can download the artifacts generated by another step inside the same pipeline
:heavy_check_mark: a step inside a pipeline can download the artifacts generated by another step which is present in the pipeline that triggered the current step's pipeline (parent pipeline)

We would like a step to access another step's artifact which is present in a sibling pipeline. Example: If you consider the below setup: pipeline A has two trigger steps which trigger pipeline B and pipeline C. Now the step Y can't access the artifacts present in step X because they are part of sibling pipelines.

```
┌───────────────────┐
│ │
│ pipeline A │
│ │
└────────┬──────────┘
│
│
│
│
│
│ ┌──────────────────┐
│ │ │
├────────────────────►│ pipeline B │
│ │ │
│ └────────┬─────────┘
│ │
│ │ ┌─────────────────┐
│ │ │ │
│ └────────────────►│ step X │
│ │ │
│ └─────────────────┘
│
│
│
│ ┌─────────────────┐
│ │ │
└──────────────────────►│ pipeline C │
│ │
└────────┬────────┘
│
│
│ ┌─────────────────┐
│ │ │
└─────────────────►│ step Y │
│ │
└─────────────────┘
```

I would like to extend the artifact download command to consider those sibiling pipeline steps also while trying to download the artifacts. Let me know if this is okay to do and if it is open for contribution.

Start by tracing the Go implementation of the artifact download command and how it currently resolves artifacts from the same and parent pipelines. Define how sibling pipelines are identified and what permissions or ambiguity rules apply, then verify that downloads from the depicted pipeline B-to-C relationship work without changing existing behavior.

Written by the indexing model from the issue text.