docs(readme): 补充「额度与计费」章节，说明两条互不相通的计费线

[cinkyzhang]

这个 PR 做了什么

只改 README.md，不动任何代码逻辑。

1. 新增「📊 额度与计费」章节

把实测结论沉淀成文档：同一账号下上游存在两条互不相通的计费线。

请求来源	上游凭据	计费落到
官方客户端（桌面端 / zcode --web）	OAuth 账号令牌	活动包（如 zcode-v3-start-plan-trust-<月日>）
本代理（plan: start-plan）	auth login 换来的凭据	每日免费池（GLM-5.3 3M + GLM-5.3-Flash 5M）

2. 两条常见问题

• 接上代理后活动包额度一直不掉 —— 说明这不是 bug，并指出正确的排查位置
• 报 code 3012 / unusual activity —— 给出观察到的触发特征与处理建议（先停手等冷却、不要立刻重试、不建议接无人值守跑批）

证据

在官方客户端里发一句「你好」，活动包立刻计费：

used_units: 0 → 10958 → 33360

同一时间段在代理侧发请求（glm-5.3-flash），逐次核对两个池：

池	请求前	请求后	变化
活动包（100,000,000）	100,000,000	100,000,000	0
每日 Flash 池（5,000,000）	4,994,592	4,986,415	−8,177

−8,177 与该批请求的 total_tokens 完全吻合；后续 341,543 token 的大批量测试同样精确落在每日池。

另外：两个身份查询同一个 billing/balance 接口，返回的额度条目数也不同（客户端 1 条 / 代理 3 条），
说明服务端是按凭据身份分视图的。

关于 code 3012

探测过程中触发过一次：

HTTP 405  {"code":3012,"msg":"request has been blocked due to unusual activity."}

观察到：它主要看流量特征而不是用量 —— 同一时间段官方客户端的正常使用完全不受影响，
被拦的全是非客户端进程发出的请求；被拦不是永久封禁，间隔一段时间会恢复。
这与 #40 的现象一致，可能也与 #47 属于同一类风控的不同强度。

说明

• 这是一份文档补充，不改变任何行为；如果方向不对，直接关掉即可
• 数据来自本人账号实测，文中不含任何令牌、设备标识或本地路径
• 如果维护者认为「代理复用客户端凭据以计入活动包」值得做成功能，我可以另外提一版实现（会单独开 PR 讨论）