ci: lint pull request titles against the conventional preset

[DutchyD]

The commit-msg hook added in #3 only guards commits made locally. A squash merge takes its subject from the PR title, which nothing validated — so a non-conventional title could still land on development.

This adds a workflow that runs the PR title through commitlint's conventional preset, the same linter and preset the local hook uses.

Notes on the implementation

Self-contained by necessity.development has neither commitlint nor commitlint.config.js — both arrive in #3, which is still open. A job that ran pnpm install && pnpm exec commitlint would therefore fail on this PR and stay broken until #3 merged. Instead the job resolves commitlint through pnpm dlx with an explicit --extends, so it needs no checkout, no install and no repo files. It works today and in either merge order relative to #3.

types: [opened, edited, reopened].edited is the one that matters: without it, correcting a rejected title would not re-run the check. ci.yml's default pull_request types exclude edited, which is why this is a separate workflow rather than a job there.

The title is passed via env:, not interpolated into run:. A PR title is attacker-controlled text; ${{ ... }} inline in a shell would allow command execution on the runner. Probed with a title containing "; echo PWNED; # — nothing executed.

No third-party action.amannn/action-semantic-pull-request is the common choice, but it maintains its own list of allowed types, which would drift from commitlint.config.js.

Verification

Ran the exact command against a tree with no commitlint.config.js, matching what CI sees:

• ci: add pr title lint job → exit 0
• added some stuff → exit 1, type may not be empty

This PR's own title is checked by the workflow it adds, so a green check here is the end-to-end test.