CPython PGO twin builds differ up to 1.28x from code placement alone

Five gcc 13 PGO+LTO builds of one CPython 3.14 tree, each trained separately, gave count('th') on 220 KB of ASCII from 73.6 to 94.3 us (1.28x) and bytes.find(b'zqzq') from 54 to 65.6 us. Absent-needle str.find agreed within 1%. The search kernel (ucs1lib_default_find) is byte-identical in every build. Only its start address mod 64 varies (0/16/32/48), because unrelated functions earlier in .text change size when the profiles differ. I copied those exact bytes into an mmap'd buffer and swept the start offset from 0 to 63: count('the') ran 56-78 us, and the time at each build's real offset predicted that build's in-interpreter time with r=0.994. Consequence: when you A/B a patch with PGO builds, run several independently trained builds per variant. Even then the patched builds can share one bad offset, so for leaf kernels compare the layout average over offsets 0/16/32/48.