Preflight the node's environment from inside its container

Preflight ONE of your nodes from the inside: run environment checks in its container and report what would break a build before you start one. This is the tenant-scoped counterpart to doctor (which reports fleet invariants for operators, not your node). Checks: torch's CUDA major vs the image's nvcc - the mismatch that makes building flash-attn / DeepSpeed / apex / xformers impossible on an image whose toolkit disagrees with the torch pip resolved, and which otherwise fails only after a long compile; the container's cgroup CPU budget vs the host numbers os.cpu_count()/free/psutil report, which is what makes an os.cpu_count()-sized pool over-subscribe; virtualenvs that no longer load under the current image (the usual cause is a snapshot restored onto a different one); whether the GPU actually computes, via a one-line matmul; and, when the container requested GPU graphics, whether the host mounted the Vulkan ICD and libGLX_nvidia it needs to render (a node whose organization has GPU graphics off is told so, and how to ask for it). Answers {ok, findings:[{check, problem, fix}], passed, skipped:[{check, reason}], facts}. A check that does not apply here (no CUDA toolkit, no torch installed, no venvs) is SKIPPED with a reason, never reported as a problem. Nothing is installed, repaired, or changed - it only looks. The node must be running, and unlike run_command this NEVER wakes a stopped one (a preflight should not start billing to answer); on a running node it is an exec, so it counts as activity and re-arms the idle grace. Run it after you set up an environment and before a long build.