fix: restore code queue native topology

docs/reference/arch.md

@@ -59,6 +59,7 @@
       - Running k3s itself inside Docker or any long-lived container is forbidden. Docker remains available for provider-gateway, target-side image builds, user workload containers, and temporary artifact extraction, but not as the k3s runtime boundary.
       - Kubernetes hostPath, local-path storage, node labels, kubelet, CNI, and `/workspace` semantics must resolve against the real computing node filesystem. For WSL nodes such as D601, a Code Queue task working in `/workspace` must see the WSL host `/home/ubuntu`, not a container-private `/home/ubuntu`.
       - If a legacy `rancher/k3s` container is present during migration, it is only an artifact source or rollback reference; it must not remain the active control plane and must be stopped before accepting the node as healthy.
+      - A computing resource node that cannot run native k3s and reach the k3s control plane through a stable Kubernetes-supported network must not be listed as an expected k3s node. Current Code Queue HA is provided inside the D601 native k3s control plane through separate read, write, and scheduler Services; D518 remains a normal UniDesk provider/File Browser node until a native k3s-agent network path is designed and verified.
     - k3s Control Bridge Boundary
       - `k3sctl-adapter` is part of the UniDesk control plane, not a workload controlled by k3s. It must remain `deployment.mode=unidesk-direct` or an equivalent UniDesk-managed host service, and must not be converted to `k3sctl-managed`.
       - The adapter exists so UniDesk can inspect, deploy, and repair k3s-managed user services. Putting that bridge inside the k3s cluster would invert the dependency order: repairing or diagnosing k3s would first require the in-cluster adapter and service network to be healthy.