fix(card): 扫码支付等流水不再被算成收入

[yeliqin666]

变更说明

校园卡流水里，食堂窗口扫码支付的记录（icon=qrCode-payment、turnoverType=二维码支付）不含任何已知的支出关键词，于是走进 _signed_amount_cents() 的默认分支，按正数显示成收入，余额走势和收支统计都跟着错。

根因是方向完全靠类型文案关键词猜；学校一加新支付渠道就会漏。改为三级判断：

1. 优先用 typeFrom：官方 ncard 账单页前端按 "1" === typeFrom 显示 +，其余一律 -，这是权威规则。
2. 缺 typeFrom 时退回原有关键词匹配（收入优先，保留「消费退款」取正的行为），并把「二维码支付 / qrcode-payment」补进支出关键词。
3. 关键词也对不上时看钱落到哪：充值 toAccount=0（或等于 fromAccount）视为留在卡里，否则视为转出。

服务端返回负数时仍原样保留；typeFrom、toAccount、fromAccount 缺失或格式异常时安全退化，不会抛错。

验证

• 每个 bug 修复都新增或更新了可复现旧问题的回归测试。
• 与已知 Issue 相关的程序错误已有明确的回归测试，并出现在 Actions 日志中。（无对应 Issue）
• 已运行相关本地测试，并在下方列出无法运行的测试或环境。
• 合并前 PR Tests / CI Gate 已通过。
• 平台相关行为已由现有矩阵覆盖，或已在下方解释额外验证范围。

测试证据

test/card/test_campus_card.py 新增 3 个用例（合成数据，不访问真实接口）：

• test_qrcode_payment_is_expense：扫码支付记为支出；在未修复的代码上得到 +850，失败。
• test_type_from_decides_direction_before_keywords：typeFrom 优先于关键词，字符串/整数都能识别。
• test_unknown_type_falls_back_to_destination_account：未知类型按 toAccount 判断方向。

uv run --frozen python -m unittest test.card.test_campus_card
OK
uv run --frozen python -m test.ci.check_test_contract
OK: 28 product test modules are covered by 5 domains.

本地环境：Windows 11，Python 3.12。

🤖 Generated with Claude Code

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

[TiaoFeng]

本人实机验证此 PR 修复了真实存在的“扫码支付流水显示异常”的问题。

结论

没有发现阻塞性问题，倾向支持合并。

[JimmyWang0417]

补充一个边界问题：题述说 typeFrom 缺失或格式异常时会安全退化，但 _optional_str() 会把 True、1.0 甚至任意对象转换成非空字符串；_signed_amount_cents() 随后把所有非 "1" 的值直接判为支出，因而异常的 typeFrom=True 会覆盖关键词和账户字段，得到错误方向。建议只接受接口约定的字符串/整数值，其他类型返回 None，让它进入既有关键词或账户回退路径，并补一个异常类型的测试。

[JimmyWang0417]

当前版本暂不支持合并。typeFrom 的异常类型处理仍可能导致错误的金额方向：_optional_str() 会把 True、1.0 等异常值转成非空字符串，随后 _signed_amount_cents() 将所有非 "1" 的值直接判为支出，覆盖关键词和账户字段的回退逻辑。请限制可接受的类型，异常值返回 None，并补充回归测试。