on.permissions schema rejects `vulnerability-alerts`, blocking Dependabot-alert pre-activation gates

[joesturge]

Bug

The on.permissions block — which sets permissions for the generated pre_activation
job (the on.steps gate) — uses a hardcoded allow-list with additionalProperties: false
that omits vulnerability-alerts. As a result, a pre-activation step that reads
Dependabot alerts cannot be granted the scope it needs, and gh aw compile rejects it.

The top-level permissions: block does support vulnerability-alerts, so the two
schemas are inconsistent.

Steps to Reproduce

Frontmatter:

on:
  schedule: daily
  workflow_dispatch:
  permissions:
    vulnerability-alerts: read   # <-- rejected
  steps:
    - id: check
      env:
        GH_TOKEN: ${{ github.token }}
      run: gh api /repos/${{ github.repository }}/dependabot/alerts?state=open --jq 'length > 0' | grep -q 'true'

gh aw compile fails schema validation on vulnerability-alerts.

Evidence

In pkg/parser/schemas/main_workflow_schema.json (main, 2026-06-18):

• The on.permissions block ("description": "Additional permissions for the pre-activation job…", ~line 2131) is additionalProperties: false and its allow-list is:
  actions, checks, contents, deployments, discussions, issues, packages, pages, pull-requests, repository-projects, security-events, statuses.
  It omits vulnerability-alerts (also id-token, attestations, models,
  copilot-requests).
• The top-level permissions block (~line 12410) does define
  vulnerability-alerts (~line 12731): "Permission level for Dependabot vulnerability
  alerts (read/none)".

pkg/workflow/permissions.go already includes PermissionVulnerabilityAlerts in
GetAllPermissionScopes(), so the engine supports it — only the on.permissions schema
allow-list is out of sync.

Expected Behavior

on.permissions should accept the same Dependabot/MCP-relevant scopes as the top-level
permissions block — at minimum vulnerability-alerts.

Impact

The githubnext/agentics dependabot-pr-bundler workflow gates activation on a step that
calls GET /repos/{owner}/{repo}/dependabot/alerts. That endpoint requires
vulnerability-alerts: read; security-events: read (code scanning) returns
HTTP 403 Resource not accessible by integration. Because the correct scope can't be
expressed in on.permissions, consumers must hand-patch the generated .lock.yml after
every gh aw compile/update.

Workaround

Manually add vulnerability-alerts: read to the pre_activation job's permissions: in
the compiled .lock.yml and re-apply after each recompile.

[pelikhan]

@copilot unify permissions ref in main JSON schema