docs(site): remove stale allowed-build-ids from upload-build-attachment and add codemod 0005 (#1497)

- safe-outputs.mdx: remove the now-inert 'allowed-build-ids' field from
  the upload-build-attachment config example and replace the stale note
  with an explanation that the field never applies to build attachments
  (which are scoped to the current run only) and is auto-stripped by the
  drop_build_attachment_allowed_build_ids codemod. Add cross-link to
  upload-pipeline-artifact which still supports allowed-build-ids.
- codemods.mdx: add missing codemod 0005
  (drop_build_attachment_allowed_build_ids, introduced in v0.42.0) to
  the registered codemods table.

Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

Author: github-actions[bot]

site/src/content/docs/reference/codemods.mdx

@@ -20,6 +20,7 @@ and contributors (how to add one).
 | `pool_object_form` | `pool: <string>` → explicit `pool:` object form (`name` / `vmImage`) | 0.30.0 |
 | `flatten_work_item_config` | `safe-outputs.{noop,missing-tool,missing-data}.work-item:` nested block → flat fields (`title-prefix`, `area-path`, `report-as-work-item`, …) | 0.37.0 |
 | `legacy_path_markers` | `{{ workspace }}` / `{{ working_directory }}` / `{{ trigger_repo_directory }}` → explicit ADO path expressions | 0.38.0 |
+| `drop_build_attachment_allowed_build_ids` | `safe-outputs.upload-build-attachment.allowed-build-ids:` → removed (field is inert; build attachments can only target the current run) | 0.42.0 |
 
 If `ado-aw compile` rewrites your source, it prints a warning to stderr naming each codemod that fired and reminding you that front-matter comments are dropped by the round-trip.
 

site/src/content/docs/reference/safe-outputs.mdx

@@ -695,15 +695,14 @@ safe-outputs:
     max-file-size: 52428800              # Maximum file size in bytes (default: 50 MB)
     allowed-extensions: []               # Optional -- restrict file types (e.g., [".png", ".pdf", ".log"])
     allowed-artifact-names: []           # Optional -- restrict names (suffix `*` = prefix match)
-    allowed-build-ids: []                # Optional -- restrict target builds (skipped when targeting current build)
     name-prefix: ""                      # Optional -- prepended to the agent-supplied artifact name
     attachment-type: "agent-artifact"    # Optional -- {type} segment in the attachments URL (default: "agent-artifact")
     max: 3                               # Maximum per run (default: 3)
 ```
 
 **Notes:**
 - Single-file only; directory uploads are not supported.
-- When `build_id` is omitted and `allowed-build-ids` is configured, the allow-list check is skipped -- the current build is implicitly trusted.
+- **`allowed-build-ids` is not supported** for this tool. Build attachments are a DistributedTask timeline attachment scoped to the current job record — they can only ever be added to the current pipeline run, so a per-build allow-list is meaningless. (If you previously had `allowed-build-ids` in your front matter, `ado-aw compile` removes it automatically via the `drop_build_attachment_allowed_build_ids` codemod.) To restrict uploads to specific builds across runs, use [`upload-pipeline-artifact`](#upload-pipeline-artifact), which still supports `allowed-build-ids`.
 
 **About `attachment-type`:** This is the `{type}` segment in the ADO build
 attachments URL (`PUT .../attachments/{type}/{name}`). It acts as a category