fix(ci): make the pull-request title check actually check the title

[NotThatKindOfDrLiz]

Problem

This repo runs a Semantic PR check, and a green tick beside it looks like proof the pull-request title was validated. It is proof of nothing. The check has never inspected a single title here.

The reusable workflow we call guards its only step like this:

- name: 🤖 Ensure Commit is Semantic
  if: github.event_name == 'pull_request'

Our workflow triggers on pull_request_target. Inside a reusable workflow github.event_name is the caller's event, so that condition is false, GitHub skips the step, and the job still reports success — usually in about two seconds.

You can see it on this repo's most recent run before this change:

success  Set up job
skipped  🤖 Ensure Commit is Semantic     <-- never ran
success  Complete job

56 of the 60 repos in the org with this workflow are in the same state. AGENT_CONTEXT.md already warns about exactly this shape of bug — "a green check can belong to a job whose if: skipped it" — and this is it, on nearly every pull request we open.

The fix

Trigger on pull_request instead of pull_request_target. That satisfies the condition the reusable workflow is actually looking for, and it is what the four repos with a working check already do (divine-mobile, divine-invite-darshan, divine-pr-repair, and divine-iac-coreconfig via its own workflow).

pull_request is also the safer trigger for this job. pull_request_target runs in the base repository's context with access to org secrets, which is why it exists for fork workflows that genuinely need them. A title check needs no secrets and no write access — only pull-requests: read, which this workflow already declares.

What to expect after merge

The check starts actually running. Any currently open pull request in this repo whose title is not a valid Conventional Commit will begin failing it. That is the check finally doing its job, but it will look sudden, so it is worth a glance at open PRs here after this merges.

Titles in this org already conform at a very high rate — all 300 of the most recent org pull requests parse cleanly — so the expected number of newly-failing PRs is low. It is just not zero.

How this was verified

Confirmed against the jobs API on divine-context and keycast (step skipped, job green) and against divine-mobile, which triggers on pull_request and genuinely runs the step. After merging, confirm the step rather than the job:

gh api repos/{owner}/{repo}/actions/runs/<run-id>/jobs \
  --jq '.jobs[].steps[] | "\(.conclusion)  \(.name)"'

A skipped 🤖 Ensure Commit is Semantic line means it is still broken.

Tracked in divinevideo/divine-context#106. Found while documenting title rules in divinevideo/divine-context#105.

🤖 Generated with Claude Code

https://claude.ai/code/session_01WYcWWWW9Hhr92Qtgz13Bvk

[mbradley]

Approving. I verified this is the identical one-line change across the fleet, and the diagnosis holds: on pull_request_target, the reusable workflow's if: github.event_name == 'pull_request' guard is false, so the title-check step is skipped while the job still reports green — the check never ran. Switching to pull_request satisfies that guard so the step runs, and it is the less-privileged trigger, which is the right choice for a title check that needs no secrets.