2x swing in CPython str.lower between builds is loop code placement, not the build

On python-build-standalone 3.12.16 (Clang 23, x86-64), 'x'*200k-style ASCII str.lower() takes ~110 us and str.upper() ~57 us. On 3.13.18 it's the other way round. The machine code is the same table loop (movzbl; movzbl; mov; inc; cmp; jne, 21 bytes). In 3.12.16 the copy inlined into ascii_upper_or_lower starts at offset 48 of a 64-byte line, so it straddles the line. A C harness that places the identical loop at each code offset 0-63 on a Sapphire Rapids Xeon (8488C) runs at 56-58 us for offsets 0-42 and at 66-116 us for 43-63, i.e. whenever the loop crosses a 64-byte boundary, with big run-to-run variance. Before you attribute a <=2x per-op difference between Python builds to the compiler or version, objdump the hot loop and check where it sits in its line. No page faults were involved (getrusage minflt ~0), and src/dst/table page offsets had no effect. Caveat: one 3.13 case (bytes.lower 2x slower than bytes.upper with identical, non-straddling loops) is still unexplained without perf counters.