[minor] IsSamePrefix 用同一个 idx 同时索引 first 和 second

问题：second 恒为长度 2 的字面量（"_C"/"GV"/"GP"/"GF"/"PI"），但循环 for (i = idx; i < endIdx; i++) 用同一个 i 去索引 first 和 second。正确语义应是 first[idx + i] 对 second[i]。

影响：调用点 CJMangledDeCompression 传入的 idx 是 StripCangjieAt 的返回值，'@' 开头时为 1，此时本次新增的 endIdx > second.Length() 会直接短路成 false。改动前是 first[1] 对 second[1]（'_' vs 'C'）同样得 false，所以本次没有引入回归，但也没有修正错位——只是把失败原因从「错位比较」换成了「长度短路」。

建议：改为 first[idx + i] != second[i]，长度校验对 first 用 idx + PREFIX_LEN、对 second 用 PREFIX_LEN。另需说明：即使这样修好，公开 API Cangjie::Demangle() 上 '@' 开头的名字仍然出不来结果——Demangler 入口的 SkipString(MANGLE_CANGJIE_PREFIX) 要求 "_C" 落在 currentIndex = 0，'@' 从未被剥离。所以验证只能在 DeCompression::CJMangledDeCompression 这一层加白盒用例；若要端到端生效，需另行在 Demangler 入口剥 '@'。

[major] atoi 没跟上 compiler 的溢出防护

问题：本行的 numberLen 由上一行的 while 循环得到，长度无上限；超出 int 范围时 atoi 是未定义行为。compiler 侧同一函数已改用 std::stoll + uint32_t 范围检查；Demangler.cpp 的 DemangleLength 也是同样情况（compiler 已改，本仓仍是 return atoi(numStr.Str());）。

影响：紧接着新增的 idx + numberLen + number > mangled.Length() 校验正是建立在这个 atoi 结果上——在最需要它的畸形输入上反而不可靠。这也是本次「三仓一致」目标上最实质的一处未达成。

建议：本仓若未禁用异常，可直接采用 compiler 的 std::stoll + 范围检查方案；否则用无异常的等价实现（手工逐位累加并检查溢出，或 std::from_chars）。注意 runtime 侧是 -fno-exceptions，三仓在这一处未必能写成同一份代码，若决定保留差异请在 PR 描述里写明理由。

Bug
⚠️ Warning

atoi has no overflow protection for unbounded digit run

numberLen comes from a digit run whose length is unbounded, and atoi(mangled.SubStr(idx, numberLen).Str()) is undefined behavior when the value exceeds int range. The new bounds check on the next line (idx + numberLen + number > mangled.Length()) is built on this result, so it is unreliable exactly on the malformed inputs it is meant to guard. Note the companion compiler PR converted the equivalent function to std::stoll with a uint32_t range check; DemangleLength in Demangler.cpp has the same atoi pattern. If this repo is built with -fno-exceptions (as the runtime is), use the exception-free equivalent — manual digit accumulation with an overflow check, or std::from_chars — and document the intentional difference from the compiler side.

In third_party/demangler/DeCompression.cpp in `ForwardName`, replace the `atoi` call for `number` with an overflow-safe conversion: either use `std::stoll` with an explicit range check against `uint32_t` max (guarded by `__cpp_exceptions`), or the exception-free equivalent using `std::from_chars` / manual digit accumulation with an overflow check, returning `idx` when the value does not fit. Apply the same fix to the `atoi` usage in `DemangleLength` in Demangler.cpp so the three repos agree.

Not useful? Reply @yanjs reject to dismiss this suggestion.

[major] 同目录下 Utils.h 未同步，MANGLE_STDPKG_MAP 存在真实的 demangle 结果分歧

（本条与本行代码无关，因 Utils.h 不在本次 diff 内，借 DemanglePackageName 内这处改动提出）

问题：issue #1123 的复现步骤指向的是三个 demangler 目录，本次只同步了其中 4 个文件。我把三仓 head 上另外 5 个共享文件也比了一遍，全部未同步：CangjieDemangle.cpp / CangjieDemangle.h / Utils.h / StdString.h / Cjfilt.cpp。其中 Utils.h 的 MANGLE_STDPKG_MAP 条目数为 compiler 65、runtime 68、本仓 65，runtime 独有 {"aa", "std.ad"}、{"bp", "std.net.native.cjvm"}、{"br", "std.ffi.java"} 三条。

影响：这张表在 DemanglePackageName 里直接决定包名还原，同一个 mangled 名在 runtime 与 cjfilt 下会 demangle 成不同结果——正是 #1123 要消灭的那类不一致。另外 StdPkgHash 的 + static_cast<uint8_t>(cPkg[id++])（compiler）与 + cPkg[id++]（runtime/tools）也未对齐，因键都是 2 字符 ASCII 暂不触发差异。

建议：本轮补上 Utils.h 的这三条映射；其余文件若不在本轮处理，请在 PR 描述里写明「本次只同步 4 个文件」以及剩余分歧与 #1123 的关系，否则 issue 关掉后这部分不一致就无人认领。

[test] 这一行是真实的行为修复，但三个 PR 都没有新增用例

问题：i % (MAX_ARGS_SIZE + 1) 是以 17 为模，i=17 得 0（应为 1）、i=18 得 1（应为 2），即嵌套声明 ≥17 层时输出的名字会丢段/错位；本次改成 i == 0 ? 0 : ((i - 1) % MAX_ARGS_SIZE) + 1 修掉了它。同一批改动里还有 DemanglePackageName 的 > 0 → > 1、ForwardName 的 while 条件（原来检查的是 idx、递增的却是 numberLen，是真越界读）以及新增的长度校验，都是行为变更。

影响：PR 自检勾的是「测试用例：不涉及（同步代码，不涉及新功能）」，与实际不符。本仓 third_party/demangler 目录下没有任何测试载体，这批行为变更在本仓完全没有回归网。

建议：至少在 compiler 的 unittests/Demangle 或 runtime 的 CheckDemangle.cpp 里补上对应用例，并在 PR 描述里说明本仓依赖哪一侧的用例做回归。