Decide: How should the stacked-PR trap be fixed, where both caller stubs (test-pull-request.yml, test-pull-request-smoke.yml, mirrored in docs/reusable-workflows.md and the hub's own workflow) filter `p? #3744

Split from #1516 by decision triage. Only this undecided item waits on the maintainer. The rest of #1516 stays there as ordinary work.

Decision needed (decision triage, 2026-11-01)

Question: How should the stacked-PR trap be fixed, where both caller stubs (test-pull-request.yml, test-pull-request-smoke.yml, mirrored in docs/reusable-workflows.md and the hub's own workflow) filter pull_request: branches: [main, develop] so a PR retargeted onto develop gets no run: drop the filter, add types: [opened, synchronize, reopened, edited], or document the no-op-push remedy?

Options, recommended first:

1. Drop the base-branch filter in both stubs and the hub (recommended): Every PR gets its run when opened, and the check sits on the head SHA, which a retarget does not change, so it carries across (verified live on aiopurpleair). The staleness allowed is the same gap the non-strict status-check policy already accepts. Costs runner minutes on rare PRs into feature branches. Stubs, docs example, and tests/test_release_guards.py change together, and PhotoCleaner's filtered copy follows. No work in flight.
2. Keep the filter, add the edited type: Every title or body edit, routine for agent-driven PRs, triggers a full rerun, and job-level skipping is unsafe since a condition-skipped aggregator reports success. No work in flight.
3. Keep the filter, document the no-op-push remedy: Cheapest and fails closed (the PR waits at "Expected"), but someone must recognize the stall. No work in flight.

Evidence: Both stubs carry branches: [main, develop] and no types:, as does the hub's own workflow. No rule text mentions stacked or retargeted PRs. The 2026-09-10 comment lays out trade-offs without a choice. The prose-gate-on-push sub-question is #3334's problem and should follow its decision. Items 1 and 2 (mypy files key, mypy-or-pyright exclusivity) stay ordinary documentation work.

Blocks: none