fix: enforce native k3s runtime

docs/reference/arch.md

@@ -54,6 +54,11 @@
       - The primary path for automated task dispatching and execution is via the local Docker socket
       - Access to the local environment via WSL SSH is reserved solely as an auxiliary path for emergency maintenance and troubleshooting, exposed only as bounded `host.ssh` probe/exec tasks
       - Automating task deployment or dispatching through the WSL SSH channel is forbidden
+    - Native k3s Runtime
+      - Any k3s server, control-plane node, agent, or worker running on a computing resource machine must be installed directly on that node's host OS or WSL distro, normally as the native `k3s` systemd service.
+      - 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.
     - Connection Management
       - When registering, a node carries an authentication token to verify its identity and declares resources such as GPU/CPU
       - The authentication token is pre-issued by the main server and configured at Provider Gateway startup