fix(post-combat-impact): 小窗口下 Combat Impact 面板溢出可见区域且不触发 +N more 裁剪

[pengx17]

现象

窗口较小时，Combat Impact 面板会超出可见区域向下溢出，且不会触发 +N more 裁剪 —— 内容被窗口边缘直接切掉。

复现（2026-08-04）：

1. History → 选一场战斗 → Replay
2. 把游戏窗口调到约 1026×684
3. 悬停内容量大的卡（本例：Fairies / 仙灵，CAUSED 视角）

面板从窗口顶部一直延伸出底部，+N more 行始终没有出现。

不是重构引入的

在 refactor/native-paired-tooltip-host（#206）和 master 952d8b23 上分别复现，两者逐行一致：相同分组、相同明细行、相同顺序、相同溢出、同样没有 +N more。两边日志也都是恰好 2 条 pair_top_alignment_adjusted。

即这是既有行为，与 #206 的抽取无关。

根因方向（未验证，有证据支撑）

裁剪判定 FitsCanvasHeight 把面板高度和根 Canvas 的矩形比较：

• BPP 取边界：primary.RootCanvasComponent.transform as RectTransform，再 Inset(canvasRect.rect, CanvasMargin)
• 游戏原生钳制取边界：_canvasForWorldBounds（decompiled/TheBazaarRuntime/TheBazaar.UI.Tooltips/BaseTooltipController.cs:135, 209-211）

这是两个不同的序列化引用（RootCanvasComponent 定义在 CardTooltipController.cs:557）。如果 _canvasForWorldBounds 是一个更小的内层安全区，而根 Canvas 更大，那么我们的高度判定就会认为"放得下"，于是既不裁剪、也不上移，面板就溢出到可见区域之外。

原生 KeepTooltipWithinBounds() 用的正是前者，所以原生 tooltip 不会越界，而 BPP 自绘面板会。

建议验证方式

在 Position 里对同一 controller 同时读出两个矩形的 canvas-local 尺寸并比对；若两者不同即可确认。修法方向是把 Combat Impact 的可用高度基准从根 Canvas 换成与原生一致的边界矩形。

影响范围

只影响小窗口 / 特定宽高比下内容量大的卡。全屏默认分辨率下未观察到。

[pengx17]

不单独立项，直接在 #206 分支修复。

[pengx17]

更正：本 issue 的判断是错的，没有 bug，不需要修。

在主路径加临时 #if DEBUG 探针实测后（数据见下），两条论断都被推翻：

root_canvas_rect=3456.0x2209.7  inset_bounds_h=2177.7  panel_h=2158.7  fits=True
aux_worldBounds=Tooltip_Aux_Canvas:2209.7   primary_worldBounds=Tooltip_P:2209.7
screen=2052x1312

1. "拿错边界矩形（safearea）"不成立：_canvasForWorldBounds 与根 Canvas 高度完全相同（均 2209.7），不存在更小的内层安全区。
2. 面板并未溢出：panel_h=2158.7 vs 可用 2177.7，确实放得下，fits=True 是正确判定，因此不裁剪是对的。实机截图确认面板底部边框完整闭合、最后一行可见。

原始截图里的截断是窗口 resize 中间态造成的：游戏渲染视口尚未跟上新的窗口尺寸，右侧黑区是未渲染区域，不是 tooltip 定位问题。稳定尺寸下不复现。

探针已撤除，工作树干净。

附带结论：+N more 裁剪路径在这份 replay 数据下始终不可达（内容量从未超过画布），因此它仍是 #206 中未经实机覆盖的部分。