Centralize label management and fix permission issues (#2018)

* fix: Allow label operations on pull requests in external plugin approval workflow

The sync-merged-pr-labels job needs pull-requests: write permission to
add/remove labels on merged PRs. Previously it only had issues: write which
is for issues, not pull requests. This fixes the permission error when
workflows try to modify PR labels from a non-contributor account.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

* fix: Handle 403 permission errors when creating external plugin intake labels

When running on PRs from fork contributors, the GitHub token may not have
permission to create labels in the repository. This is expected and should
not cause the workflow to fail. Allow the ensureLabel function to gracefully
handle 403 Forbidden errors in addition to 422 (label already exists) errors.

This fixes the sync-pr-state job failure in external-plugin-pr-quality-gates.yml
when run on PRs from external contributors.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

* refactor: Centralize label management into a single workflow_dispatch workflow

Create a new 'setup-labels' workflow that is manually dispatched and handles
all label creation and updates. This workflow:
- Creates all labels used by the repository
- Updates descriptions if labels already exist
- Reports success/failure counts
- Fails if any labels cannot be created

All individual workflows now assume labels exist and will fail (loudly) if
they don't. This makes it clear to maintainers when the setup-labels workflow
needs to be dispatched:

- label-pr-intent.yml
- skill-check-comment.yml
- external-plugin-approval-command.yml
- external-plugin-command-router.yml
- external-plugin-rereview.yml
- external-plugin-rereview-command.yml
- eng/external-plugin-intake-state.mjs

This approach is better because:
- Single source of truth for label definitions
- Avoids permission issues with fork contributors
- Clear failure modes when labels are missing
- Easier to maintain consistent label configuration
- No more scattered label creation logic across workflows

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

* Remove unused ensureLabel methods and managedLabels constants

Labels are now centrally managed by the setup-labels workflow and
assumed to exist in all other workflows. Removed:

- ensureLabel() methods from all 6 workflows and 1 JS module
- managedLabels constants that were only used by ensureLabel
- Promise.all() calls that invoked ensureLabel for each label
- Updated syncManagedLabels in skill-check-comment.yml to remove ensureLabel call

All workflows now assume labels exist and will fail if they don't,
which is the desired behavior—it signals maintainers to dispatch the
setup-labels workflow when new labels need to be created.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

---------

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

.github/workflows/skill-check-comment.yml

@@ -42,27 +42,7 @@ jobs:
               }
             };
 
-            async function ensureLabel(name, { color, description }) {
-              try {
-                await github.rest.issues.createLabel({
-                  owner: context.repo.owner,
-                  repo: context.repo.repo,
-                  name,
-                  color,
-                  description
-                });
-              } catch (error) {
-                if (error.status !== 422) {
-                  throw error;
-                }
-              }
-            }
-
             async function syncManagedLabels(issueNumber, desiredLabels) {
-              await Promise.all(
-                Object.entries(managedLabels).map(([name, config]) => ensureLabel(name, config))
-              );
-
               const currentLabels = await github.paginate(github.rest.issues.listLabelsOnIssue, {
                 owner: context.repo.owner,
                 repo: context.repo.repo,