ci: label pull requests by ownership area

[junwu168]

Problem

Pull requests are not consistently classified by the OpenPI area they change. Maintainers must inspect each diff before they can filter, route, or summarize work by ownership boundary.

Value

Automatic, deterministic area labels make the PR queue easier to scan and filter without adding a third-party service or asking contributors to classify their own changes.

Approach

• Add the official GitHub Pull Request Labeler, pinned to the reviewed v7.0.0 commit.
• Classify stable OpenPI ownership boundaries: workflows, subagents, background terminals, setup, UI, GitHub infrastructure, and documentation.
• Run on pull_request_target so fork PRs can receive labels, while reading only base-branch configuration and never checking out or executing contributor code.
• Grant only contents: read and pull-requests: write to the labeling job.
• Synchronize configured labels when a PR's changed-file set changes.
• Add repository tests that pin the action contract, permissions, security boundary, and label taxonomy.

Validation

• node --test tests/github/automation-workflows.test.ts — 6 passed.
• ./node_modules/.bin/biome format . — passed.
• ./node_modules/.bin/biome lint . --error-on-warnings — passed.
• node_modules/typescript/bin/tsc --noEmit — passed.
• node scripts/run-tests.mjs — 1,006 passed, 5 failed, 1 skipped. Four existing setup-config process tests exhausted the sandbox's file-watch limit (EMFILE), and one subagent backend test could not create Pi session state under ~/.pi (EPERM).
• bun run check and bun run test were not run because Bun is unavailable in this environment; the installed underlying check and test commands were run directly as listed above.

Impact

• User-visible behavior: qualifying pull requests receive one or more area:* labels and Markdown changes receive documentation.
• Model-visible context/tools: None.
• Runtime/lifecycle: None; this is repository automation only.
• Persisted config/data: adds GitHub workflow and label rules; workflow runs update PR label assignments.
• Compatibility/risk: low. The privileged event has a narrow token and cannot execute pull-request code. Required labels already exist in the repository.

[tt-a1i]

Exact-head merge-gate review at e7398b7 against main 6286bd8. The pull_request_target workflow does not checkout or execute PR code, reads configuration from the trusted base commit, pins actions/labeler to a verified commit, grants only contents:read and pull-requests:write, and syncs only configured taxonomy labels. Two independent security reviews found no actionable findings; focused tests and bun run check passed locally, all required CI checks are green, and all configured labels exist.