docs: clarify HWLAB control-plane failure status

docs/reference/hwlab.md

@@ -150,6 +150,8 @@ HWLAB 当前真实 runtime 由 issue/CLI 选中的 node/lane 决定。只读观
 trans D601:k3s kubectl -n hwlab-v03 get deploy,svc,pod -o wide
 ```
 
+HWLAB node/lane control-plane 的 PipelineRun 失败定位优先使用 UniDesk 受控状态入口，而不是先手工拼 TaskRun/Pod 查询：`bun scripts/cli.ts hwlab nodes control-plane status --node <node> --lane <lane> --pipeline-run <name>`、`trigger-current --wait` 的返回对象，以及异步 `bun scripts/cli.ts job status <jobId> --tail-bytes 12000` 都应直接暴露失败 TaskRun、Pod、container、失败 step、termination reason 和 bounded `trans <node>:k3s logs --namespace hwlab-ci --pod <pod> --container <container> --tail 200` 查看命令。默认状态输出只给诊断命令和受控摘要，不打印完整 pod 日志、Secret、完整 DSN、API key 或其他可复制凭据。遇到 service build 的 `step-publish` 失败时，下一步先跑 `bun scripts/cli.ts platform-infra sub2api status --target <node>` 和 `bun scripts/cli.ts platform-infra sub2api validate --target <node>`，区分 Sub2API/proxy 整体故障和单上游 transient，再选择受控 rerun 或修复 artifact-publish/envRecipe 的有限 retry。
+
 `hwlab-cloud-api` 和 `hwlab-edge-proxy` 在集群内可使用 `6667` Service 端口；对外入口以选中 target 的 publicExposure/public URL 为准。Node/Bun/undici 的 Fetch 实现会按 Fetch bad-port 规则拒绝 `6667`，因此任何需要代理、转发、探测或服务间访问该端口的 Node 实现都必须使用 `node:http`/`node:https`、已有 repo-owned HTTP helper，或改用不触发 bad-port 的受控代理端口；不要把 Fetch bad-port 造成的 `fetch failed` / 502 误判为 Service DNS、PVC、数据库或 trace 数据缺失。G14 local details 见 `docs/reference/g14.md` 和 G14 节点 `/root/docs/hwlab-g14-workspace.md`；D601 node-scoped target 以 `config/hwlab-node-lanes.yaml` 的 `nodes.D601` 和 `lanes.v03.targets.D601` 为准。
 
 D601 原生 k3s 是 D601 node-scoped runtime 的正式控制面；D601 legacy 对照也使用同一 native k3s guard。任何 D601 k3s 操作都必须显式使用 UniDesk route `D601:k3s` 或等价的 `/etc/rancher/k3s/k3s.yaml`，不能使用裸默认 kubeconfig：