feat: support glob patterns in `allowed` for `add-labels` safe-outputs

[yskopets]

🤖 This comment has been generated by Claude Code.

Summary

safe-outputs: add-labels supports two list-based constraints:

• blocked — filters out label names matching glob patterns (e.g. ~*, *[bot])
• allowed — restricts labels to an exact-match allowlist

The two lists are documented and treated symmetrically in the schema (ListJobConfig has both Allowed []string and Blocked []string with the glob-support note on Blocked), but the runtime enforcement is asymmetric:

// blocked — uses glob matching (safe_output_validator.cjs)
const isBlocked = blockedPatterns.some(pattern => matchesSimpleGlob(labelStr, pattern));

// allowed — uses exact string match only
validLabels = validLabels.filter(label => allowedLabels.includes(label));

Motivation

There are real use cases where glob patterns in allowed would be useful:

• team-* — allow any team-scoped label without listing every team
• priority-* — allow any priority tier label
• area/* — namespaced label schemes

Currently, workflows that use such label naming conventions must enumerate every variant in allowed or omit the list entirely (permitting all labels).

Proposed change

Extend the allowed list in add-labels (and by extension remove-labels) to support the same matchesSimpleGlob logic already used for blocked. This would make the two lists consistent in capability.

// After
validLabels = validLabels.filter(label =>
  allowedLabels.some(pattern => matchesSimpleGlob(label, pattern))
);

The change is backwards-compatible: exact strings are valid glob patterns that match themselves.

Notes

• The same asymmetry likely applies to other ListJobConfig-based outputs (add-reviewer, assign-milestone) — worth checking.
• If exact-only allowed is intentional for security reasons (avoiding accidental over-permissioning), this issue can serve as the tracking point for documenting that rationale instead.