chore(deps): let dependabot cover the VS Code extension

[chethanuk]

Description

.github/dependabot.yml declares two ecosystems, gomod and github-actions, both at /. The
repo has 9 npm manifests, so the VS Code extension is entirely unmanaged.

The evidence that the gap matters is already in the tree.
extensions/vscode/package.json:110-116:

"resolutions": {
  "undici": ">=7.28.0",
  "form-data": ">=4.0.6",
  "js-yaml": "^4.2.0",
  "minimatch": "^9.0.7",
  "@typescript-eslint/typescript-estree/minimatch": "^9.0.7"
}

Someone is patching CVEs by hand, in a package dependabot never looks at.
extensions/vscode/yarn.lock is tracked and is # yarn lockfile v1 — Yarn
Classic, which dependabot's npm ecosystem supports.

Scope is deliberately narrow — one directory, not nine

Path	Included	Why
/extensions/vscode	yes	tracked yarn.lock, hand-pinned CVEs
/pages	no	its lockfile is gitignored (.gitignore:13) — that's your policy call, not mine
/ and the six npm/*/	no	the six declare no dependencies at all; the root declares only optionalDependencies on those six 0.0.0 platform stubs — pure noise

  - package-ecosystem: npm
    directory: /extensions/vscode
    schedule:
      interval: weekly
    open-pull-requests-limit: 5
    ignore:
      # yarn.lock already resolves @types/vscode far above the declared
      # engines.vscode floor (^1.74.0). Realign the two deliberately rather
      # than let a bot churn a version no CI job builds or type-checks.
      - dependency-name: "@types/vscode"
    groups:
      vscode-dependencies:
        patterns:
          - "*"
        update-types:
          - minor
          - patch

Two parts of that are load-bearing rather than decoration:

• @types/vscode is ignored. package.json declares "engines": {"vscode": "^1.74.0"} and
  "@types/vscode": "^1.74.0" — they read like a contract, but that contract is already broken
  in the tree today:

  $ grep -A1 '^"@types/vscode' extensions/vscode/yarn.lock
  "@types/vscode@^1.74.0":
    version "1.125.0"
  

  ^1.74.0 permits anything <2.0.0, so yarn resolved to 1.125.0 — the extension is
  type-checked against VS Code 1.125 APIs while declaring it runs on 1.74.0+. The ignore rule
  just stops a bot dragging it further while nothing validates the result (see below). Fixing it
  properly is a behaviour change for a separate PR.

• update-types: [minor, patch]. The pending majors here are genuinely breaking: eslint ^8 → 9 (flat-config migration, and .eslintrc.json is present), @typescript-eslint ^6 → 8,
  and @types/node ^18 → 24. A bare "*" group would bundle all of them into one unreviewable
  PR; this way majors arrive individually.

The thing you should weigh before merging

Nothing in CI builds or tests this extension.

$ grep -rn -E "yarn|vsce|extensions/vscode" .github/workflows/
(no matches)

No workflow runs yarn install, jest, webpack, eslint, or vsce package for
extensions/vscode — even though package.json defines compile, test, lint, and
package scripts and there are 10 test files under src/**/__tests__/. So every dependabot PR there would be checked only by
ci.yml, which is Go-only and entirely unaffected → green with zero validation. Merging on
green would be merging blind. If you'd prefer an extension CI job first, happy to close this and
revisit after.

Also worth naming: resolutions is not maintained by dependabot — it's a yarn field, so this
PR reduces future manual pinning but does not retire the existing block.

#340 (gomod) and #347 (actions) are both still open, so adding a third ecosystem to a backlog
that isn't being serviced is a fair objection. This entry is grouped and capped at
open-pull-requests-limit: 5, so it adds at most one PR per week.

Verification

$ python3 -c "...parse .github/dependabot.yml..."
entries: [('gomod', '/'), ('github-actions', '/'), ('npm', '/extensions/vscode')]

$ git diff origin/main -- .github/dependabot.yml | grep '^-' | grep -v '^---'
(no output — pure addition, both existing entries byte-identical)

Limitations

I have not seen dependabot actually run this config — a schema-valid file is not proof the first
run behaves as intended, and expect a larger burst on that first run than in the steady state. I
did not add an extension CI job, which is arguably the change that should come first.

Type of Change

• Bug fix (non-breaking change that fixes an issue)
• New feature (non-breaking change that adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Refactoring (no functional changes)
• Documentation update
• CI / Build / Tooling

How Has This Been Tested?

• yaml.safe_load parses; asserted 3 entries, the new one's limit/ignore/groups shape, and
  that versioning-strategy is absent
• Confirmed the diff removes zero lines — both existing entries untouched
• Re-confirmed every premise first-hand: lockfile tracked + Yarn Classic, /pages lockfile
  gitignored, the engines/@types/vscode version contract, the five resolutions pins
• Confirmed no workflow references the extension

Checklist

• My code follows the project's coding style
• I have performed a self-review of my code
• I have added tests that prove my fix is effective — n/a, dependabot config
• New and existing unit tests pass locally with my changes
• I have updated the documentation accordingly (not applicable)
• I have signed the CLA

AI assistance: Claude Code helped research and verify this change. I reviewed the full diff
and take responsibility for it.

[github-actions]

✅ OpenCodeReview: No comments generated. Looks good to me.