Automate yarn dedupe for Dependabot security PRs

What happened

PR #3996 was a Dependabot security bump of form-data 2.5.5→2.5.6 in /workspaces/scorecard. The bump changed the hasown dependency range from ^2.0.2 to ^2.0.4, introducing a duplicate resolution in yarn.lock (both hasown@2.0.2 and hasown@2.0.4 present). A human had to manually trigger /fs-fix run yarn dedupe and commit the changed yarn.lock file at 20:46 UTC — over 4 hours after the PR was created — to consolidate the duplicate. The same pattern occurred on the same day on PR #4000 (launch-editor bump in install-dynamic-plugins), which also required manual /fs-fix for yarn dedupe.

What could go better

The repo already solves this problem for Renovate PRs via the yarnDedupeHighest post-update option in .github/renovate.json. However, Renovate has vulnerabilityAlerts disabled, so Dependabot handles security alerts — without the benefit of automatic deduplication. The existing automate_renovate_changesets.yml workflow already triggers on Dependabot PRs (it checks for dependabot[bot] in the author) and has write access to the branch, but only generates changesets — it does not run dedupe. This means every Dependabot security PR that introduces a transitive dependency version change requires manual human intervention to run a mechanical yarn dedupe command. Confidence is high: the pattern is clearly reproducible (two instances on the same day) and the root cause is well-understood (Dependabot lacks Renovate's postUpdateOptions).

Proposed change

Extend the existing automate_renovate_changesets.yml workflow (or create a sibling workflow) to run yarn dedupe in the affected workspace for Dependabot PRs before generating changesets. The workflow already checks out the PR branch with write access and has Node.js set up. The implementation would: (1) detect the affected workspace from the changed yarn.lock path, (2) run yarn install and yarn dedupe in that workspace directory, (3) commit any lockfile changes. This mirrors what the version-bump.yml workflow already does (lines 107-109: yarn dedupe step after version bumps). An alternative approach is to enable vulnerabilityAlerts in .github/renovate.json, letting Renovate handle security updates with automatic deduplication — but this may conflict with the team's current security alerting preferences.

Validation criteria

The next 3 Dependabot security PRs on this repo that introduce transitive dependency changes should have yarn dedupe run automatically without requiring manual /fs-fix intervention. The PRs should arrive with a clean, deduplicated yarn.lock and pass CI without human lockfile maintenance.

Generated by retro agent from https://github.com/redhat-developer/rhdh-plugins/pull/3996

Start with .github/automate_renovate_changesets.yml and inspect its existing Dependabot trigger, checkout, Node.js setup, and changeset steps. Compare the deduplication step in version-bump.yml and the yarnDedupeHighest setting in .github/renovate.json. Done means affected Dependabot security PRs receive a deduplicated yarn.lock and pass CI without manual /fs-fix intervention.