feat(platform): support channel-key header for dedicated cloud channels

专属云渠道用户（复用主站域名，如 api.ucloud-global.com）调用 API 报校验错误：
网关需要 channel-key 请求头来定位「去哪个渠道的用户库查验凭据」，缺失时
AK/SK 报 171 Signature VerifyAC Error、OAuth 报 174 Token Not Exists。

新增 profile 级可选配置 channel_key（落 config.json，omitempty），经
attachHandlersWithManager 这一唯一汇聚点注入，覆盖全部 client 构造路径。

- config.go: channel_key 配置项、--channel-key 全局 flag 字段、mergeConfigIns
  覆盖、--config 表格新增 ChannelKey 列（渠道标识非凭据，不脱敏）
- client.go: newChannelHeaderInjector，与凭据注入并列而非并入——channel-key 是
  接入点配置（同 base_url），与 auth_mode 正交，不属 spec「一个请求只携带一种
  凭据机制」的约束对象
- root.go: --channel-key 全局 flag（os.Args 扫描 + 注册，缺一不可）
- configure.go: config / config add / config update 三处入口，与 base-url 对齐；
  channel-key 归入「连接类参数」并早于远程校验应用，否则专属云 profile 会陷入
  「配置时校验即 171 → 永远配不上」的死锁

空值完全不注入该头（键不存在，而非空值），保证主站与独立域名渠道用户线路字节
零变化——刻意区别于同文件 Cookie/Csrf-Token「空值也照旧 set」的存量契约。

真实 combo 账号 + 真实网关实测：AK/SK 171→0、OAuth 174→0；Go 规范化后的
Channel-Key 网关照常接受；config add 一步建 profile 可用。

已知局限（继承自 --base-url，非本次引入）：os.Args 扫描只认 --channel-key X
空格形式，--channel-key=X 静默失效。

另记录：channel-key 不匹配时网关同样返回 174，与 token 过期同码，会使既有的
authRetCodeWhitelist 误触发一轮刷新+重放。已在 client.go 注释留档，本次不改
控制流。