Build/Test Tools: Set explicit retention periods for build artifacts.

[obenland]

Summary

Four actions/upload-artifact steps inherit GitHub's 90-day default, which is far longer
than any of them are used for. This sets an explicit retention-days on each.

Workflow	Artifact	Days	Rationale
reusable-build-package.yml	wordpress-develop	1	Same-run handoff to upgrade-tests-develop
reusable-performance-test-v2.yml	performance-*	1	Same-run handoff to the compare job
reusable-end-to-end-tests.yml	failures-artifacts*	14	Debugging output; not consumed by any workflow
reusable-test-core-build-process.yml	wordpress-build-*	14	Read across runs (see below)

reusable-prepare-gutenberg.yml already sets retention-days: 7 and is unchanged.

Why

Three of the four are retained long after anything can read them:

• wordpress-develop and performance-* are same-run handoffs. Each is downloaded by a
  later job in the same workflow run and never read again, but both currently sit for 90
  days. Every copy older than its own run is dead weight.
• failures-artifacts* is debugging output from failed end-to-end runs. No workflow
  consumes it, and its value to a human drops off quickly after the run fails.

wordpress-build-* is the only one read across runs, so it keeps a longer window.

This repository currently stores over 214,000 Actions artifacts. Setting retention
explicitly documents how long each artifact is actually needed instead of inheriting a
default that no one chose, and keeps stored volume proportionate to use.

Notes for reviewers

• wordpress-build-* keeps 14 days because it is genuinely read across runs, in two
  places: performance.yml looks up wordpress-build-<sha> to decide whether to run a
  before subject, and WordPress Playground fetches wordpress-build-<PR#> when someone
  opens the preview link posted by pull-request-comments.yml. Playground previews now
  expire 14 days after a pull request's last push rather than 90; stale pull requests
  need a rebase, which Playground's own error message already instructs.
• Re-running failed jobs more than 24 hours after the original run will fail to download
  the 1-day artifacts. Re-running all jobs rebuilds them.

Verified with actionlint (the pinned version from reusable-workflow-lint.yml): no errors.

Trac ticket: https://core.trac.wordpress.org/ticket/65845

Use of AI Tools

AI assistance: Yes
Tool(s): Claude Code
Model(s): Claude Opus 5
Used for: Tracing every artifact producer and consumer across .github/, verifying which
artifacts are read across workflow runs rather than within one, measuring current artifact
storage via the GitHub API, the four one-line workflow changes, and drafting this
description. I directed the investigation, chose the retention values and scope, and
reviewed the result.

---

This Pull Request is for code review only. Please keep all other discussion in the Trac ticket. Do not merge this Pull Request. See GitHub Pull Requests for Code Review in the Core Handbook for more details.

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

[github-actions]

The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the props-bot label.

Core Committers: Use this line as a base for the props when committing in SVN:

Props obenland.

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.