CI: don't hard-fail on the confirmed TSan-can't-start-here runner limitation

The real Gitea Actions run on this project's own registered runner just
failed exactly as CONTRIBUTING.md already anticipated it might:
FATAL: ThreadSanitizer: unexpected memory mapping, the same signature
already documented as a sandbox/container seccomp restriction blocking
personality(ADDR_NO_RANDOMIZE), which TSan needs to start at all. Build,
test suite, and ASan/UBSan all passed -- only the TSan step failed, on an
environment issue, not a code issue.

Fixed the CI step itself rather than just noting the failure: it now
classifies each binary's TSan run as PASS, a known flake (that exact
FATAL signature and nothing indicating an actual race was found), or a
real failure (anything else -- a genuine data race, a crash, any other
error). Only a real failure fails the build. Verified the classification
logic locally against four cases (a synthetic real race report, a plain
assertion failure, the known flake signature alone, and a clean pass) --
each classified correctly -- and against this sandbox's own six test
binaries, all six of which hit the real flake (this sandbox has never
been able to run TSan either) and correctly did not fail the build.

This does NOT mean TSan verification is happening in CI -- it means CI no
longer conflates "TSan couldn't start" with "the build is broken."
Updated CONTRIBUTING.md and CLAUDE.md from "whether the runner can execute
TSan is unverified" (a hedge) to the now-confirmed fact that it can't, and
corrected an overclaim in README.md that the suite is "regularly run under
ThreadSanitizer" -- as far as this project has been able to confirm, TSan
has not actually completed a run in any environment it's been built in
yet, local sandbox or CI. ASan/UBSan remain the real, run, load-bearing
sanitizer coverage.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01UqJpkdJ6Njnt1pw3CbghzB

README.md

@@ -259,8 +259,20 @@ cell directly and never touch the snapshot. `mem`-backed buffer growth
 never mutates a buffer address a reader might be reading (Section 5.7):
 growth always allocates a new buffer and publishes it, never reallocates in
 place. `tests/test_concurrency.c` exercises this under concurrent reader and
-writer threads, and the suite is regularly run under ThreadSanitizer and
-AddressSanitizer (see `.gitea/workflows/ci.yml`).
+writer threads. The suite is regularly run under AddressSanitizer/
+UndefinedBehaviorSanitizer, both locally and in CI (see
+`.gitea/workflows/ci.yml`), and this is not aspirational — ASan caught a
+real heap-use-after-free in the snapshot-reclamation logic during
+development (see the `reclaim_gate` note in `src/internal.h`).
+ThreadSanitizer is configured the same way but, as of this writing, has
+not actually completed a run in either environment this project has been
+built and tested in so far — the local development sandbox and this
+project's own CI runner both block the `personality(ADDR_NO_RANDOMIZE)`
+syscall TSan needs to start (see `CONTRIBUTING.md` for the confirming
+tests in each case). CI's TSan step is written to not fail the build over
+that specific, known-benign failure, which means a green CI run is not
+evidence TSan actually executed — stated plainly here rather than left to
+be assumed from CI showing green.
 
 ## Security