feat: support npm/pnpm Dependabot PRs and automate pnpm packageManager updates

[j7an]

What

Add a supported npm/pnpm dependency-update path to shared-workflows.

This work has two related parts:

1. Extend the reusable dependency-safety workflow to understand pull requests
   generated by Dependabot’s package-ecosystem: "npm" integration, including
   pnpm-managed repositories with committed package.json and
   pnpm-lock.yaml files.
2. Provide an automated way to keep the exact pnpm version in
   package.json#packageManager current.

Dependabot can update dependencies declared in package.json and their
lockfile entries, but it does not treat this field as an updateable dependency:

{
  "packageManager": "pnpm@<exact-version>"
}

Consumer repositories should continue to own their Dependabot configuration,
schedules, workflow triggers, permissions, and repository-specific validation.
Shared behavior should remain in reusable workflows with thin local callers.

Implementation may be split into multiple PRs after the design establishes the
boundaries and rollout order.

Why

shared-workflows currently supports dependency-safety extraction and
automated handling for GitHub Actions and Python dependency updates. It
recognizes Node manifests and lockfiles as dependency-related paths, but treats
package.json, package-lock.json, yarn.lock, and pnpm-lock.yaml as
unsupported and fails closed.

Consequently, adding an npm ecosystem entry to a pnpm consumer today would
create Dependabot PRs that cannot pass the standard dependency-safety contract
without manual intervention.

Separately, an exact packageManager version is part of the reproducible
toolchain contract for Corepack/pnpm repositories. Leaving that field to manual
maintenance allows the package-manager version to drift even while ordinary
dependencies remain automated.

A centrally documented and tested contract would:

• Make npm/pnpm consumers consistent with existing sibling workflow policy.
• Preserve fail-closed dependency verification.
• Keep manifest and lockfile updates reviewable.
• Avoid repository-specific updater scripts being copied between consumers.
• Preserve exact package-manager pinning while keeping it maintainable.

High-level how

Complete a design/specification before implementation. The design should cover
at least the following areas.

npm/pnpm Dependabot support

• Document the consumer-owned package-ecosystem: "npm" configuration for npm,
  pnpm, and other applicable Node repositories.
• Extend dependency extraction, classification, advisory lookup, verdict, and
  reporting for the approved npm/pnpm Dependabot update shapes.
• Support scoped package names and grouped updates.
• Prove that manifest and lockfile changes belong to the reported dependency
  update before allowing the dependency-safety gate to pass.
• Continue to fail closed on ambiguous, incomplete, malformed, or unsupported
  changes.
• Preserve existing Actions and Python behavior.

Automated pnpm packageManager updates

Select and document one automation mechanism during specification:

1. Reusable shared workflow: add a workflow_call workflow, modeled on the
   existing pre-commit autoupdate workflow, with caller-owned schedule and
   workflow_dispatch triggers. The workflow would detect an eligible newer
   pnpm release and open or refresh a dependency PR.
2. Renovate: use Renovate’s native support for the packageManager field,
   while defining how Renovate-authored PRs interact with the existing
   Dependabot-only dependency-safety and non-bot gate behavior.
3. Another mechanism identified during design: acceptable if it preserves
   the same security, reproducibility, and thin-caller boundaries.

A documentation-only Dependabot configuration is insufficient because it
cannot update packageManager and does not resolve the current
dependency-safety parser gap.

Design decisions to resolve

The specification should resolve these choices and record their trade-offs:

• Package-manager updater mechanism.
• Whether npm dependency-safety support and the pnpm updater share a release or
  roll out sequentially.
• Eligible pnpm update policy: current-major updates, all stable updates, or
  another explicit rule.
• Whether major pnpm upgrades use separate PRs or require manual opt-in.
• Whether a package-manager update may also update pnpm-lock.yaml, and how
  lockfile consistency is verified.
• Authentication and PR authorship, including GitHub App use and any
  GITHUB_TOKEN fallback.
• How updater-authored PRs receive CI, security scanning, and the required
  dependency-safety gate.
• Behavior when a repository’s configured pnpm major is outside Dependabot’s
  currently documented support.
• Any additional choices discovered during specification brainstorming.

Acceptance criteria

Specification

• An approved design specification defines the supported npm/pnpm update
  shapes, package-manager updater mechanism, trust boundaries, failure
  behavior, and rollout order.
• The specification resolves every design decision above or explicitly
  excludes it with rationale.
• Current GitHub and package-manager compatibility is revalidated during
  specification; unsupported versions are not silently treated as
  supported.

Dependabot and dependency safety

• Documentation provides a consumer-owned
  package-ecosystem: "npm" configuration compatible with the established
  schedule, cooldown, grouping, and commit-message conventions.
• Dependabot PRs changing supported Node manifests and lockfiles can be
  completely and deterministically mapped to their dependency updates.
• Supported direct, grouped, scoped-package, and approved lockfile update
  shapes receive the appropriate advisory scans and dependency-safety
  verdict.
• Unexpected manifest fields, unrelated file changes, incomplete
  extraction, malformed data, or unsupported update shapes fail closed with
  an actionable diagnostic.
• Existing GitHub Actions and Python dependency-safety behavior remains
  unchanged.

pnpm packageManager updater

• The selected automation detects when an eligible newer stable pnpm
  version exists.
• An outdated exact packageManager value results in an opened or refreshed
  pull request; an already-current value is a no-op.
• The updater never pushes directly to the default branch.
• The updater changes only the files approved by the specification.
• The resulting packageManager value remains an exact, valid pnpm version.
• Any associated lockfile update is produced and verified using the pnpm
  version selected by the updated toolchain contract.
• Unsupported versions, invalid manifests, registry failures, and
  incomplete authentication fail with actionable diagnostics and do not
  create misleading success PRs.
• Authentication behavior and the limitations of any GITHUB_TOKEN
  fallback are documented.
• Updater-authored PRs run the consumer’s normal CI and security checks and
  receive an intentional dependency-safety gate result.

Documentation and tests

• Reusable-workflow documentation explains consumer setup, inputs,
  permissions, triggers, generated PR behavior, and failure modes.
• Contract and runtime tests cover positive, no-op, grouped, malformed,
  unsupported, and fail-closed cases.
• Tests assert semantic requirements and do not hardcode current dependency
  versions, action versions, workflow versions, or commit SHAs.
• Existing shared-workflows validation remains green.