ci: switch pr-title.yml + label.yml back to pull_request_target

[EricAndrechek]

Context

In PR #55 we introduced `.github/workflows/pr-title.yml` and `.github/workflows/label.yml` using the `pull_request` trigger, because `pull_request_target` requires the workflow file to already exist on the default branch (GitHub's security rule for base-repo permissions on PR payloads). Using `pull_request_target` on a PR that was adding those files caused the `Validate` check to never report, stalling the required-status-check merge gate. See the trigger-revert commit and its message on #55 for the full write-up.

Why we want `pull_request_target`

• pr-title.yml: `pull_request_target` carries base-repo permissions, so fork PRs can post / update the sticky comment explaining the Conventional Commits format. Under `pull_request` the `GITHUB_TOKEN` is read-only on fork PRs, so fork contributors see the failing `Validate` check but don't get the helpful comment. Once feat: add AI automation stack and OSS governance for open-source launch #55 lands, the workflow file is on main, so `pull_request_target` becomes safe and useful.
• label.yml: same story — labels apply via `actions/labeler` on `pull_request` for internal PRs but silently no-op on fork PRs. Moving to `pull_request_target` post-merge lets forks get auto-labeled too.

Scope

Two-line change, one commit:

1. `.github/workflows/pr-title.yml`: `on.pull_request` → `on.pull_request_target` (keep same `types`)
2. `.github/workflows/label.yml`: same swap

Open a PR, let it pass the now-enforced `Validate` check (no change to title behavior for maintainer PRs, so should pass), squash-merge.

Safety note

Both workflows were deliberately written to only read `github.event.pull_request.*` from the webhook payload and never check out PR code — the standard `pull_request_target` safety criterion. No additional review needed beyond confirming neither file gains an `actions/checkout` step before the switch.

Acceptance

• Fork PR opened against the repo gets the `Validate` check reporting + (on fail) a sticky comment with the format.
• Fork PR gets auto-labeled by `actions/labeler` per `.github/labeler.yml`.
• Internal PR behavior unchanged.

References

• PR feat: add AI automation stack and OSS governance for open-source launch #55 — the work that introduced these workflows
• AGENTS.md §"Repository Automation (three tiers)" — describes intended behavior

[EricAndrechek]

Reopening — this issue was auto-closed when PR #64 merged because the PR body had `Closes #56` in it, but the pull_request_target switch was actually reverted before merge after hitting a chicken-and-egg: switching a workflow's trigger in a PR means neither the old nor new trigger fires on that PR, so the `Validate` check never reports and merge stalls.

The real fix is a dual-trigger transition:

1. Update pr-title.yml + label.yml to declare BOTH `on: pull_request` AND `on: pull_request_target` simultaneously. Both fire during the transition — internal PRs get two runs (harmless), fork PRs get the `pull_request_target` run (with full permissions).
2. Land that PR. Main now has both triggers.
3. Follow-up PR drops the `pull_request` trigger once the `pull_request_target` one is proven working.

Still low priority, still small scope.

---

— Posted by Claude Code on behalf of @EricAndrechek

@claude