test_str: the UCS4 adaptive search path is never exercised #160501

Summary

Objects/stringlib/fastsearch.h compiles adaptive_find once per character
width. The UCS4 copy never ran under the entire test suite, because the only test
that reaches the adaptive path, string_tests.BaseTest.test_adaptive_find, uses
ASCII strings.

Evidence

Coverage from a --coverage build of main running the full suite
(./python -m test -j4, 552 files, 52,070 tests):

Function 'ucs4lib_adaptive_find'   Lines executed:0.00% of 39
Function 'ucs2lib_adaptive_find'   Lines executed:66.67% of 39
Function 'ucs1lib_adaptive_find'   Lines executed:71.79% of 39
Function 'asciilib_adaptive_find'  Lines executed:79.49% of 39

Why the existing test misses it

The adaptive branch is taken only when, in Objects/stringlib/fastsearch.h:800:

• the haystack is at least 2500 characters,
• the needle is at least 100 characters (or the haystack at least 30000),
• the needle is at least a third of the haystack.

test_adaptive_find meets all three, but with 'a' and 'b', so the code that
runs is the ASCII or UCS1 instantiation. Nothing in the suite builds a haystack
that wide-and-long out of non-BMP characters, so the UCS4 instantiation stays
cold.

Proposal

Add a test next to test_find in Lib/test/test_str.py that repeats the same
shape with '\U0001d11e' and '\U0001d11f'. With that test present,
ucs4lib_adaptive_find goes from 0.00% to 89.74% of 39 lines, and the remaining
branches are the count and reverse-search modes, which are separate entry points.

This is a test-only change, so it does not alter behaviour. I have it ready and
will open a PR against this issue.

CPython versions tested on

CPython main branch (3.16.0a1+)

Operating systems tested on

Linux

Linked PRs

• gh-160501: Cover the UCS4 adaptive search path in test_str #160502