Add the shared pull-request template (taphouse sync)

[tap]

Syncs the new canonical pull-request template from TapHouse (see tap/TapHouse#5, which adds it to the canonical set and to scripts/sync.sh). None of the 13 family repos had one.

Single file, no code or CI changes.

The template asks for what changed and why, a Verification section stating what was actually built and run versus what CI will gate (plus the family's measured-not-remembered rule for performance claims), and a delete-what-does-not-apply list of the recurring cross-repo concerns.

Relevant here: the measured-not-remembered rule in Verification, given this repo's ITU-T compliance battery and the instruction-count ratchet under bench/icount/ — a PR that moves a workload's count should say so and cite the number; and notebook re-execution, noting this repo's notebooks are generated by tools/notebook/build_*.py rather than hand-edited, which is worth stating in a PR that touches them.

It is created only-if-missing and deliberately not drift-guarded, following the .claude/settings.json precedent rather than the .clang-format one: it is prose for humans, so this repo is free to tailor it. Trim the bullets that don't apply.

---

Generated by Claude Code

[tap]

CI is red here on macOS AppleClang, and it is not caused by this PR. Flagging it once with the evidence rather than papering over it.

99% tests passed, 2 tests failed out of 181
  114 - itu_echo.EchoStability<float>            (Failed)
  179 - Float32Parity.ToneRowWithNarrowbandGuard (Failed)
      tests/test_float32.cpp:166
      max_level_dbm0a(...) < r.gate  ->  actual 42.337837234992982 vs -55, fs 16000

Why this PR isn't the cause. The entire diff is one file, .github/pull_request_template.md, 40 insertions, no C++ touched. The branch base is 0682238, which is also the current main HEAD — and main's own last CI run on that exact commit ("Bump TapHouse drift pin to v5", 2026-07-23) concluded success. So the same tree that passed four days ago fails today.

What changed is the runner image. The macOS runners now report AppleClang 21.0.0 / Xcode 26.5 and ship CMake 4. That image move is independently corroborated: the same update broke configure in tap/AmbiTap-Max#18 and tap/MuTap-Max#14 with Compatibility with CMake < 3.5 has been removed from CMake, which needed a min-api pin bump to fix. main here simply has not been re-run since the image changed, so it is untested rather than known-good on the new toolchain.

Scope: macOS-only, and specific to this repo's float32 gates. Green in the same run: Linux Clang, Linux GCC, Windows MSVC, Hexagon cross (QEMU), Cortex-M55 cross (QEMU), ASan + UBSan, the instruction-count ratchet, clang-format and drift. And it is not a blanket AppleClang 21 problem across the family — tap/AmbiTap#24's build-test (macos-appleclang) job is green on the same runners today. MuTap carries the family's tightest numerical assertions (measured ITU-T thresholds), which is exactly what a codegen change would trip first.

Worth a real look, not a tolerance nudge. 42.34 dBm0(A) against a −55 gate is roughly a 97 dB miss. That is far too large for floating-point drift, so the narrowband guard or suppressor is likely not engaging at all on this codegen rather than merely landing slightly off. Two float32 tests failing together points at the float32 path systematically.

Not fixing it in this PR. It is unrelated to the template, and I cannot reproduce it: Linux Clang and GCC both pass, and I have no macOS available in this environment, so any change would be guesswork rather than a diagnosis. It deserves its own issue and a reproduction on the new toolchain — happy to open one with this evidence if that is useful.

---

Generated by Claude Code

[tap]

Tracked as #31, with a one-flag bisection to try first: macOS is the only platform where the float32 FFT routes through vDSP rather than Ooura (TAP_DSP_FFT_ACCELERATE defaults ON for Apple), and both failing tests are float32 — so building with -DTAP_DSP_FFT_ACCELERATE=OFF should separate a vDSP behavior change on the Xcode 26.5 SDK from AppleClang 21 codegen.

This PR itself is unaffected — one markdown file, no C++.

---

Generated by Claude Code