卡密充值与兑换接入统一订单号与支付流水号

此前卡密核销虽已建订单，但订单号硬编码 CARD{卡ID}、渠道交易号硬编码
card_pass_{卡ID}，均不受后台前缀控制；且核销产生的资金流水没有挂到
订单上（order_number 为 NULL），订单详情页的「支付流水号」恒为「—」。

ChargeCard：
- 新增 allocate_redeem_order_number()：走 OrderRepository 统一分配器，
  消费后台「订单前缀」（payment_order_prefix）。
- 新增 card_pass_transaction_number()：BusinessNumber::candidate(flow_prefix)，
  消费后台「流水号前缀」（payment_flow_prefix）。
- 两条兑换路径（redeem_asset_card / redeem_vip_card）替换硬编码取号；
  create_redeem_order 接收调用方传入的交易号。
- 账本重放（replayed）时回取已落库订单号，不再把本次新分配的号回给前端。

FinancialFlowService：
- record_card_pass_payment()：会员卡（0 元、无账本参与）直接落一条
  与订单关联、零分录的 order_payment 流水；record() 新增
  allow_empty_entries 通道（prepare_entries 拒绝 delta=0，占位分录不可行）。
- record_order_event() 新增凭证结算模式：豁免「金额必须 > 0」与
  「资产类订单不得记现金流水」两条门槛（卡密核销既无第三方现金流入，
  订单还可能为 0 元或以积分计价）。
- attach_order_to_ledger_flow()：账本提交后把流水补挂到订单上，
  event_type 归一为 order_payment，使「支付流水号」可反查。
- is_successful_order_payment() 认可 card_pass 凭证结算；
  is_external_recharge() 把 card_pass 与 balance/points 一并列为平台内部
  结算方式，不再为卡密充值伪造现金出账分录（现金在售卡时已确认）。

关键取舍：随机订单号不得进入 LedgerCommand 的 metadata —— payload_hash
覆盖 metadata，会破坏账本幂等重放（实测撞 uniq_operation_key 后报
aksrt_ledger_idempotency_conflict），因此订单关联改在账本提交后补挂。

测试：新增 tests/admin/card-pass-order-numbers.test.cjs 钉住上述约束；
容器内三类卡密实测通过（订单号/渠道交易号/支付流水号三项均带后台前缀，
流水行分别携带 balance:in / points:in / 零分录），重放幂等恢复正常。

.gitignore

@@ -62,6 +62,7 @@
 !/tests/admin/charge-cards-dependency.test.cjs
 !/tests/admin/charge-cards-pagination.test.cjs
 !/tests/admin/charge-cards-form-constraints.test.cjs
+!/tests/admin/card-pass-order-numbers.test.cjs
 !/tests/front-submit/
 /tests/front-submit/*
 !/tests/front-submit/video-cover-contract.test.cjs