[KevinZhang19870314]

EVO/Mastercard 有两条静默结算轨，区别在 ptk 里装的是哪种凭证：network_token
（缺省）铸一枚带 cryptogram 的网络令牌，扣款报 type=networkToken；gateway_token
不铸币，直接装卡自己的 EVO 网关（COF）令牌，扣款报 type=token。后者用于卡没有
网络令牌的情形（绑卡走免二次验证流程时 EVO 不下发），以及无人值守场景。

改动：

• payment-tokens evo-create 新增 --credential，取值原样转发为请求体的 credential。
  判据是 flag 有没有出现，不是真值判断 —— 与 --provider-id 同一写法，刻意如此：
  空串与拼错的取值必须原样上送，由平台以 INVALID_REQUEST fail-closed。CLI 若把它
  折叠成「没声明」，平台会按缺省铸出网络令牌，而调用方以为拿到的是网关令牌形态，
  直到扣款时才发现走的是另一条轨，而那时钱已经动了。

• 输出的 Type 行改为按本次声明的凭证形态渲染（网关令牌轨显示 Gateway Token (COF)），
  成功提示同步区分。此前两条轨都硬写 Network Token，一次排查正因此把网关令牌扣款
  读成了网络令牌扣款 —— 本次工作的起因恰恰是「看不出走了哪条轨」，不该在出口再种
  一个。ACTIVE 守卫的错误信息一并去掉 network 限定，它对两条轨都成立。

  用本次请求声明的 credential 而非响应事实作为判据，是因为平台对无法识别的取值
  以 INVALID_REQUEST 拒绝、不静默回落到缺省轨 —— 所以走到渲染这一步就意味着声明
  的那条轨就是实际走的那条。

• 请求体的 type 仍是 network_token：它是令牌种类，credential 是 EVO 轨内部的凭证
  形态，两者是不同维度，平台正是在这个 type 下再按 credential 分流。

测试：新增 tests/credential.test.ts 七条（给了 / 没给 / 空串 / 拼错各一条，type
维度不变一条，输出两条）。全量 1053 passed。两处新护栏都做了负向验证：把 present
判断改回真值判断，只有「空串原样上送」那条红；把 Type 行改回硬编码，只有「不再
谎称 Network Token」那条红。

版本 0.10.5 → 0.10.6（新增 flag，按本仓惯例走 patch）。package-lock.json 的
workspace 版本同步更新 —— CI 的 check:lockfile 查的就是这个，2026-11 已连漏两次。