fix(LLVMCG): 成员表重名/联合类型字段不再打断布局配对，ExceptHandler.name 取到槽 9
类别：a 编译器缺陷（TPC 侧）
现象：翻译 TransPyV/App/lib/core/Gen/AsyncGenMixin.vp 时 `self._add_local(trans, hd.name)`
（:667）的第 2 个实参求值失败并终止编译。基址诊断给出的事实链：类 ExceptHandler
（%"831ce86a2fd82c0..." 即 astaux.vp）成员表 10 项 =
['parent','pool','lineno','col_offset','end_lineno','end_col_offset','children','children','type','name']
（'children' 重复一次），struct body 10 槽 =
[i8*, AST*, MemManager*, i32×4, list*, AST*(type), i8*(name)]，字段 'name' 计算偏移 = 10
⇒ 越界（正确槽 = 9）。
判据与修法（两条，均已写进代码注释与告警报文）：
1) 布局配对断链：成员表里 'children' 的声明类型是**联合类型折叠后的通用指针**
（`list[rawptr[AST]] | t.CPtr` ⇒ i8*），而 body 槽是具体指针（%"...list[...]"*）⇒
原配对只比 `is` / `str()`，在这一条断链，其后所有条目不再消费槽位 ⇒ 目标字段退化为
"base + 表内下标"（'name' ⇒ 1 + 9 = 10）。修：两侧都是指针时复用存储/建 body 侧同一
判据 `_MemberSlotAccepts`（通用指针 i8* 放行、具体指针按被指类型），标量仍走严格比较
——不引入新的过配对。修后 type = 8、name = 9 ✓。
2) 重名条目使长度判据失真：`_expected_count_pre = len(class_members) + vtable` 把重复项
也算一槽 ⇒ 误判"body 不完整"而用**带重复项的表**重建 body（本模块布局比其它模块多一
槽 ⇒ 跨模块 ABI 撕裂）。新增判据：表有重名**且** body 槽数恰等于「去重名数 + vtable」
⇒ 认定 body 已是权威布局（来自定义模块 stub），只报事实、不重建。
另在"未被 body 配对命中"的回退路径上，把"成员表含重名条目 + 表项数/去重项数 + 该
返回值取自回退路径可能失准"作为事实告警报出（每类一次）。
验证：冒烟复刻本现场（表含重名 'children' 且其类型为联合 i8*；body 10 槽）——逐字段
1..9 全部命中（parent=1 … children=7、type=8、name=9），无重名的自洽表行为不变；
FuncGen / StructGen 两文件 py_compile 通过。
TermiNexus
bd92dfdadf