CI: label PRs that add a skill duplicating an open PR

## Context

PR #313 adds an instruction-level guardrail (`.claude/rules/skills-contributing.md` + CONTRIBUTING.md pre-flight checks) that steers agents to check the catalog and open PRs before adding a skill. The test in #313 shows it catches duplicates, but it relies on the agent actually following the instructions.

This issue tracks a deterministic, low-noise CI complement: flag when a PR adds a new skill that collides with another **open** PR.

## Proposal

A GitHub Actions workflow that:

1. Determines the new skill directories this PR adds (files `skills//SKILL.md` with status `added`).
2. For each other open PR, checks (via the API) whether it also adds `skills//SKILL.md` with the same ``.
3. On a name collision:
- adds the `duplicate` label to the PR, and
- writes the detail and a link to the colliding PR in the job summary.
When the collision is resolved, the label is removed.

## Why a label (instead of a comment)

- Works on fork PRs, where a plain `pull_request` comment cannot be posted (read-only token).
- Idempotent: adding/removing a label is clean and doesn't accumulate comments.
- Filterable: `is:pr is:open label:duplicate`.
- The `duplicate` label exists by default in GitHub repos, so it likely needs no setup.

## Security

The labeler must run on `pull_request_target` to have `pull-requests: write`. This is safe **only because it never checks out or runs the PR head code**, it only reads PR metadata via the API and toggles a label. Do not add `actions/checkout` of the fork code to this workflow.

Minimal permissions: `pull-requests: write`, `contents: read`.

## Scope and constraints (decided in #313)

- **Name-collision only**, not semantic similarity. Same-topic/different-name (e.g. `llm-cost-optimization` vs `reduce-token-spend`) stays the job of the human/agent pre-flight checks; CI fuzzy matching would be too noisy.
- **Not** matching against already-merged skills, editing an existing `skills//SKILL.md` is a legitimate change, not a duplicate.
- **Non-blocking:** the label is a signal for reviewers, not a hard merge gate.

## Out of scope

- Hooks (too intrusive for an open-source contribution flow, per #313 discussion).
- Inline PR comments (possible later via a `pull_request` + `workflow_run` two-stage pattern; not needed for v1).

## Notes

Intentionally kept out of #313 to keep that PR docs-only; this is a separate `ci:` concern with its own review surface (token permissions, fork behavior).