Track clang-p2996 issues that affect this repository

Upstream bugs in [bloomberg/clang-p2996](https://github.com/bloomberg/clang-p2996) that we work around or that constrain how we use the fork's clang-tidy. When one is fixed: bump `.github/clang-p2996-commit`, confirm the Clang Tidy job is green, and either remove the workaround or note here why it stays.

| Upstream | Symptom here | Workaround | When fixed |
|---|---|---|---|
| [#342](https://github.com/bloomberg/clang-p2996/issues/342), fix [PR #353](https://github.com/bloomberg/clang-p2996/pull/353) (open, awaiting review) | `^^derived::operator()` rejected when the call operator comes from a using-declaration ("cannot take the reflection of a using-declarator"); rejects-valid, GCC accepts | #276 excludes types with base classes from `is_maybe_lambda` | Keep the exclusion; closure types have no bases, so it remains a correct refinement. Once the pin is bumped, `is_protocol_conformant_v` no longer needs it to pass clang-tidy. |
| [#349](https://github.com/bloomberg/clang-p2996/issues/349), fixed by [PR #351](https://github.com/bloomberg/clang-p2996/pull/351) (merged 2026-09-08 as bde8bcf3); pin bumped in #316 | `define_aggregate` with a member type spelled as a qualified name under a pointer or cv-qualifier (`^^const std::type_info*`) yields a field with a broken qualifier location; clang-tidy's renamer checks segfault (#306 CI) | None on `main`: #306 landed after the pin bump and spells `^^const std::type_info*` inline, so the alias workaround was never merged | Done. The fix is in the type-location filler, not `define_aggregate`, so any spelled qualified type under a pointer or cv-qualifier is covered. |
| [#350](https://github.com/bloomberg/clang-p2996/issues/350), fixed by [PR #352](https://github.com/bloomberg/clang-p2996/pull/352) (merged 2026-09-12 as 0664c3f6); pin bump in #357 | `vtable->[:entry:]` on an lvalue pointer trips "-> base must be a pointer prvalue" in assertion-enabled builds only; release builds (CI) are unaffected | None in code; the constraint was not to build the pinned toolchain with `LLVM_ENABLE_ASSERTIONS=ON` for use on this code | Nothing to remove. Once #357 merges, assertion-enabled local builds of the pinned toolchain compile `protocol.hh`, and `array->[:m:]` also works. |

Not bugs, noted so they are not re-reported: [#230](https://github.com/bloomberg/clang-p2996/issues/230) (`^^std::int32_t` rejected; [expr.reflect]/5.1 applies to the identifier form).