修复构建阻塞与过期测试，补 npm test 入口 (WORK-20)

[lbtsm]

修掉 WORK-20 里的三个仓库自身阻塞点：typecheck / build 现在能干净退出，npm test 一次跑完 7 个测试。

⚠️ 先看这里：本分支的基线包含未提交的本地改动

分支基于 c482cb1 chore(agent): baseline — uncommitted work from the local directory——那是 Multica runtime 把本地工作目录里尚未提交的改动固化成的一个提交，不是我写的，内容是 src/chain/sol/sync.ts、src/utils/time.ts、test/sol_sync_retry_test.js、以及新增的 src/chain/xrp/xrp.ts。

合并前请先确认 c482cb1 里前三个文件的改动是否本来就要进 main；xrp.ts 已按仓库 owner 的裁决在 86daf54 里删除（见下）。

由此还得出一个和 issue 描述不同的事实：xrp.ts 在 origin/main 上根本不存在。我在临时 worktree 里验证过 origin/main 的 tsc --noEmit 退出码是 0——构建阻塞完全来自这份本地未提交的 WIP，不是 main 上的存量问题。问题 2、3 则是 main 上真实存在的（main 上那个过期测试同样失败，也同样没有 test 脚本）。

建议用 squash 合并：xrp.ts 里带着一个硬编码的 XRP 钱包 seed，虽然文件已删，但仍留在本分支的历史提交 c482cb1 里。squash 只把最终 diff 落到 main，能避免把它带进主干历史。

1. 删掉 xrp.ts 与 xrpl 依赖（2caeef9 → 86daf54）

src/chain/xrp/xrp.ts:1 导入 xrpl，但 package.json 从未声明它，tsc 报 TS2307，typecheck / build 恒为 exit 2（noEmitOnError=false，所以产物照出，但退出码不能当门禁）。

一开始按 issue 的默认做法在 2caeef9 里把 xrpl 加进了 dependencies。仓库 owner 随后确认该文件不需要，所以 86daf54 把它连同依赖一起删掉了：

• 删除 src/chain/xrp/xrp.ts（全仓库没有任何模块引用它，chain.ts 里也没有 xrp 分支，删除不影响任何运行路径）
• 从 dependencies 移除 xrpl
• package-lock.json 逐字节还原成 main 的版本

净效果：本 PR 相对 main 完全不碰 package-lock.json，npm audit 的 14 个漏洞面原样不动；TS2307 从根上消失，不需要靠加依赖或改 tsconfig 来绕。

2. 过期测试改成行为断言（f4dd61c）

test/sol_handler_saved_fields_test.js 原本把 handler.ts 当纯文本读进来，断言 13 行源码原文出现过。handler.ts 重构后 from 走 publicKeyToBytes()、数值字段走 normalizeEventNumberHex()，那 13 条断言全部过期（issue 只点了 from 一条，实际不止）。

没有去刷新字符串字面量——那只能撑到下一次重构。改成驱动 SolEventHandler.crossOut / crossIn，断言真正落库的那行 mos 记录，共 8 个用例：

• crossOut 全字段：user 的 base58 与 from 的 32 字节原文、链 id / 金额的偶数长度无前缀 hex、tokenAmount / amountOut 取自 source_amount、bridgeAmount 仍是十进制串、sourceAmount 字段不得回归，外加 Log 信封（EventId 98 / Topic）和 bridge api 的请求参数（checksum 后的 EVM 地址、按 decimals 还原的金额、affiliate）
• to_token 全零时回落到配置的 native 地址
• 不支持的 bridgeMint：只报警、不落库
• 事件名不匹配时直接忽略
• crossIn 全字段 / 可选字段缺失时的 "00" 默认值与 toToken 回落到 bridge mint
• RefundEvent 打 isrefund

没有改任何业务代码，是把断言对齐到源码，不是反过来。

用的 stub 手法和 mysql_duplicate_test.js 已有的一致——替换模块导出（insertMos / requestBridgeData / alarm），不碰网络和数据库。

做过变异验证：把编译产物里的 data.set("from", publicKeyToBytes(...)) 改回 normalizeEventValue(...)，新测试失败（actual: 'mosv35...' vs expected: [Array]），改回来又通过——它确实能抓住原测试想守的那个回归，而原来的文本断言分辨不了。

3. 加 npm test 入口（5b9dbfd）

新增 scripts/run-tests.sh + "test": "bash scripts/run-tests.sh"。先 build（多数测试 require("../app/...")），再逐个子进程跑，打印每个文件的 PASS/FAIL 加总计，有失败就退出非零，可以直接当 CI 门禁。通过的测试输出被吞掉、只回显失败的（这些脚本 stdout 很吵）。SKIP_BUILD=1 可复用已有 app/。

按 issue 的约束没有引入任何测试框架，也没有改用 node --test——这 7 个脚本是顶层 assert 风格而非 node:test 用例，换框架等于全部重写。

失败路径也验证过：临时塞一个必失败的测试，runner 报 FAIL + 7 passed, 1 failed, 8 total，退出码 1。

验收结果

四条全绿，真实命令输出贴在 issue 评论里。

验收项	结果
npm run typecheck	exit 0，无报错
npm run build	exit 0，app/ 17 个 js 对应 src/ 17 个 ts
npm test	7 个测试全 PASS，exit 0
git status	只剩 Multica runtime 自己的未跟踪产物（.multica/、.agent_context/、.claude/、CLAUDE.md），非本次改动

影响面

• 相对 main 没有任何依赖变化（package.json 只多一行 test script，package-lock.json 零改动）。
• 删除 src/chain/xrp/xrp.ts：src/ 内无人引用，chain.ts 无 xrp 分支，运行路径不受影响。
• test/sol_handler_saved_fields_test.js 从「读源码文本」变成「跑真实 handler」，会 stub 模块导出；同一进程内跑完会还原。
• 其余 6 个测试、src/ 业务代码、CI / 发布配置均未改动。

未做（在 issue 划定的边界内）

• 没动 npm audit 的 14 个漏洞升级。
• 没建 eslint 配置、没装 eslint（package.json 里那个 eslint script 依旧是空指望）。
• 没读、没提交 config.json 和两个 *.local。

[lbtsm]

历史里带了 XRP 钱包 seed，改用干净分支重开：#2（内容完全相同）。本分支即将删除。