optimize_speed 下异常语义受 GTest 注册数量与启动分配布局影响

[pikasTech]

问题

Linux optimize_speed 配置启用 Arg/方法缓存后，仅把一个 threading.lock_rlock GTest 拆成三个独立 GTest 注册，就会让与线程无关的 Python 3 异常测试稳定失败：

• pikaMain.python3_typed_except_runtime_matrix
• pikaMain.python3_unpack_value_errors

保持相同线程实现和测试脚本，只恢复为单个 GTest 注册后，两项测试重新通过。该现象说明 runtime 缓存行为受到进程启动阶段分配布局或地址变化影响，存在潜在的缓存键、失效或对象生命周期问题。

复现条件

• Ubuntu 22.04 Docker 开发镜像
• pika_config_optimize_speed.h
• 基线提交：94c0d053fb1fcd63ef16dd943ae19d3afd7e3964
• 在 module-test.cpp 额外增加两个空或线程相关 GTest 注册，重建后定向运行上述两项测试

已有证据

• 干净基线：两项通过。
• 仅应用 Lock/RLock C 实现变更：两项通过。
• 再应用拆成三个 GTest 注册的 module-test.cpp：两项失败。
• 恢复为单个 GTest 注册、测试内部依次执行三个脚本：两项通过。
• 当前线程锁修复采用单注册规避，没有修改 runtime 缓存。

验收

• 在 optimize_speed 下，增加或调整无关 GTest 注册不改变 typed except、unpack 错误捕获结果。
• 定位并修复缓存键、失效或生命周期根因。
• 增加不依赖偶然链接/堆布局的回归测试。
• default、minimal、pool、float 语义不回归，资源占用总体不膨胀。

目标合并分支: master

[pikasTech]

v1.14.0 已于 2026-07-18 正式发布。本 Issue 按发布裁决转入发布后处理并保持开放；Release 说明已披露 optimize_speed 下测试结果受注册和启动分配布局影响的已知边界。本次发布不宣称缓存键、失效或生命周期根因已修复。