[guillaume-flambard]

Why

The Mergify policy refuses a PR that touches a sensitive path, but says so only inside the "Mergify Merge Queue" check, and Mergify's own labelling (pull_request_rules) is a paid feature that is not active (autoloop T-M2b, REQ-M04, memolabs-dev/memo-bridge#149).

What

.github/workflows/sensitive-paths.yml: on pull_request_target (opened, reopened, synchronize, ready_for_review), for same-repository PRs only, it

1. reads the -files ~= pattern from .mergify.yml at the PR's base SHA, through the API, so the label can never disagree with Mergify;
2. lists the PR's files (and previous names of renamed files) through the API;
3. when one matches: adds needs-human-review (created if missing) and posts one comment naming the paths, updated in place on later pushes.

It never checks out or runs PR code; PR data reaches the shell through env, never through ${{ }} in the script. Token permissions: contents: read, issues: write, pull-requests: write, top level {}. The label is informational: Mergify already refuses these PRs, and the label also blocks it (label != needs-human-review).

Verification

• Dry run of the same script against the eight canary PRs of 2026-10-17: the four sensitive ones (memo-bridge#156, cuesheet#83, problem-intelligence-engine#33, uni-protocol#36) are matched with the right path, the four others are not. Both pattern spellings are handled: memo-bridge's unquoted line and the quoted, double-escaped lines elsewhere (uni's trust paths included).
• YAML parsed and the run: block compared byte for byte with the tested script; bash -n passes.
• Not yet run on GitHub: pull_request_target uses the base branch's copy, so this PR cannot exercise itself. After merge, closing and reopening this repository's negative canary will run it.

This PR touches .github/: the owner merges it.

Refs memolabs-dev/memo-bridge#149