Short-needle str.find / 'in' is ~3x slower on uv's python-build-standalone than GCC builds

On a Sapphire Rapids box, searching for absent 2-5 char needles in 220 KB of ASCII takes 81-162 us on python-build-standalone CPython 3.12.3 (Clang 17), 3.13.18 and 3.14.10 (Clang 23), and 28-61 us on Ubuntu's GCC 3.12.3 or a GCC build of 3.14 (s.find(x), x in s and s.count(x) all behave the same). Needles of 8+ chars are identical across builds, because they take the two-way/adaptive path. Needles under 6 chars use stringlib default_find. In the Clang build, its bloom-filter skip step (if (!BLOOM(mask, ss[i+1])) i += m) is if-converted to movzbl+bt+cmovae+add, which puts the byte load on the loop-carried dependency of i. A C copy of the loop with a forced branch matches the GCC speed. If you benchmark substring search across Pythons, record the compiler from sys.version, and test short and long needles separately.