fix(ci): prevent spurious Dependabot PR failures from auto-approve and @types/vscode bumps

[SebTardif]

Problem

Dependabot PRs were consistently showing as failing / not auto-merging:

• Every Dependabot PR had a red "auto-approve" check (see current open PRs chore(deps-dev): Bump @types/node from 25.9.3 to 26.0.0 #140, chore(deps-dev): Bump @types/vscode from 1.120.0 to 1.125.0 #141, chore(deps): Bump actions/checkout from 6.0.3 to 7.0.0 in the actions group across 1 directory #142).
• Some updates (e.g. @types/vscode) caused real npm run package failures.
• Others were intentionally skipped for auto-merge (majors).

Root causes

1. auto-approve.yml included dependabot[bot]. This workflow triggers on pull_request.
   Dependabot pull_request runs receive no repository secrets/vars ("Secret source: Dependabot").
   The actions/create-github-app-token step always failed with:

   The 'private-key' input must be set to a non-empty string.

   This left a permanent failing status check named "auto-approve" on all Dependabot PRs.

2. dependabot-auto-merge.yml (the working one, on pull_request_target) already handled approval + gh pr merge --auto --squash for patch/minor.

   • @types/node 25→26 and actions/checkout 6→7 were classified semver-major → intentionally skipped (manual review).
   • @types/vscode 1.120→1.125 was semver-minor but produced:

     @types/vscode ^1.125.0 greater than engines.vscode ^1.90.0

   (vsce enforces this.)

Changes

• Remove dependabot[bot] from the actor list in auto-approve.yml. Only SebTardif + release bot go through it now.
• Add @types/vscode to the npm ignore list in dependabot.yml with explanation.
• New Dependabot PRs will no longer run the broken job or receive breaking @types/vscode bumps.
• Updated internal contrib notes.

Dependabot will remain automatic for true patch/minor updates that don't violate engine constraints. Majors (per Dependabot metadata) continue to require manual review per existing policy.

[SebTardif]

Update: The failure on this PR was not caused by the Dependabot fixes.

What failed

• All relevant checks passed: full ci matrix (unit + integration + build), DCO, auto-approve (now correctly skips for non-dependabot), CodeQL, etc.
• Only red: Gitleaks secret detection (in the security workflow).

Root cause

The gitleaks job used a very brittle install:

GITLEAKS_VERSION=$(curl -s https://api.github.com/.../releases/latest | grep tag_name | cut ... | sed 's/v//')
curl .../v${GITLEAKS_VERSION}/gitleaks_${GITLEAKS_VERSION}_linux_x64.tar.gz ...

• No GITHUB_TOKEN → unauthenticated rate limit (60 req/hour).
• When rate limited (or transient), the API returns an error object instead of the release JSON.
• grep produces an empty version string.
• Download URL becomes invalid → 404 → tar fails.

This is pre-existing (unrelated to the two files changed in the original commit). It happened to flake on this run.

Fix pushed

• Added commit pinning Gitleaks to 8.30.1 (current latest) with a comment.
• This is the same pattern used for other pinned tools/actions in the repo.
• New push to the branch (fix/dependabot-auto-approve) will trigger fresh runs.

Once the new security run completes it should be green. The Dependabot-related changes themselves are working (note that "auto-approve" now succeeds cleanly on this non-Dependabot PR, and Dependabot PRs going forward won't get the spurious failure).

The original two changes remain:

• Stop running the secret-requiring auto-approve logic for dependabot[bot].
• Ignore @types/vscode in Dependabot (prevents engine vs types version mismatches that break vsce package).

Ready for merge after the re-run is clean.