Drift detection consolidate-jobs ignores --filter when multiple caller jobs share a workflow run

## Summary

When using per-account caller jobs in `pipelines-drift-detection.yml` (to stay under the 256 job limit), the `consolidate-jobs` CLI command downloads **all** `drift-detection-unit-*` artifacts from the workflow run, ignoring the `--filter` flag. This causes each account's consolidation to include drift results from all other accounts.

## Reproduction

Caller workflow with per-account jobs:

```yaml
jobs:
GruntworkPipelinesVsmtDev:
uses: .../pipelines-drift-detection.yml@v4
with:
pipelines_drift_detection_filter: "vsmt-dev/**"
pipelines_drift_detection_branch: drift-detection-vsmt-dev

GruntworkPipelinesVsmtPrd:
uses: .../pipelines-drift-detection.yml@v4
with:
pipelines_drift_detection_filter: "vsmt-prd/**"
pipelines_drift_detection_branch: drift-detection-vsmt-prd

GruntworkPipelinesVsmtStg:
uses: .../pipelines-drift-detection.yml@v4
with:
pipelines_drift_detection_filter: "vsmt-stg/**"
pipelines_drift_detection_branch: drift-detection-vsmt-stg
```

## Observed behavior

The `Consolidate Jobs` step for VsmtPrd reports `vsmt-dev` units in its output:

```
# VsmtPrd / Consolidate Jobs
pipelines_drift_detection_filter: vsmt-prd/**
"drifted_unit_count": 33,
"failed_unit_count": 61,
"units": {
"vsmt-dev/_global/access-control-apply-role": { ... } <-- WRONG: vsmt-dev unit in vsmt-prd consolidation
"vsmt-dev/_global/access-control-plan-role": { ... }
...
```

Compare with VsmtDev which reports 26 drifted / 32 failed and VsmtStg which reports 26 drifted / 29 failed — while VsmtPrd reports 33/61 (the aggregate).

## Root cause

GitHub Actions artifacts are scoped to the **workflow run**, not to individual caller jobs. All three callers upload artifacts named `drift-detection-unit-{id}` to the same namespace. The `consolidate-jobs` CLI downloads all artifacts matching `drift-detection-unit-*` via the GitHub API and doesn't filter them by the `--filter` value.

## Why per-account jobs are needed

A single-job pattern would exceed the **256 job limit** per workflow. Our repo has 329+ units across 3 accounts (84 dev + 91 stg + 154 prd), and this will grow as more accounts are enabled.

## Suggested fixes

1. **Namespace artifact names** — Prefix artifacts with the filter or branch name (e.g., `drift-detection-vsmt-dev-unit-{id}`) so each caller's artifacts are isolated
2. **Fix `consolidate-jobs` filtering** — Have the CLI actually apply the `--filter` flag when selecting which downloaded artifacts to process
3. **Document the limitation** — If per-account caller jobs are not supported, document that the single-job pattern is required and recommend splitting into separate scheduled workflows to work around the 256 job limit

## Environment

- `pipelines` CLI: v0.54.1
- `pipelines-actions`: v4.10.0
- `pipelines-workflows`: v4 (fae9d97)

Start with the consolidate-jobs CLI command and pipelines-drift-detection.yml, then reproduce the per-account caller-job setup described in the issue. Trace how drift-detection-unit-* artifacts are selected and compare the --filter value with the downloaded units. Done means each consolidation includes only its account's drift results and the reproduction no longer reports units from other accounts.

Written by the indexing model from the issue text.