Fleet Linux node NODE_TOKEN and env security

Found by Task 10181's security review (the local container node got these fixes; the cloud fleet node has the same two weaknesses). 1. On a cloud Linux node, jaahd.service loads node.env as an EnvironmentFile, so NODE_TOKEN sits in skynetd's environment. Every tmux client the daemon runs sends its whole environment to the fleet tmux server, whose socket and `tmux-<uid>` directory belong to the session user `skynet`. A runner can move the socket aside, listen in its place, and capture NODE_TOKEN from the daemon's next client call. `session_user.run_as_session_user` runs its tmux client without `env=`, so it inherits os.environ. Apply `env_helpers.scrub_node_token_from_environ` on Linux fleet nodes too (today it covers Windows and the local edition), or pass every tmux client an allowlisted environment. 2. `clauded_wt.py` and `open_term.py` run as the daemon and call `env_helpers.load_fleet_env()`, which reads `$JAAH_HOME/env` into os.environ. That file is in a directory the session user can write. A runner can set `JAAHD_CTL`, `LD_PRELOAD` or `PYTHONPATH` there and get code run as skynetd. Task 10181 refuses a file from another uid in the local edition only. Do the same on the fleet, after confirming who legitimately writes that file there. Out of scope: the local edition, which Task 10181 already fixed. Done means: - A runner-owned listener on the fleet tmux socket receives no NODE_TOKEN from the daemon. Test or recorded reproduction cited. - skynetd never loads a `$JAAH_HOME/env` written by `skynet`. Covered by a test. - jaahd suite and `./dc check quick` are green.

Fleet Linux daemon now scrubs NODE_TOKEN (tmux-listener test proves no leak) and refuses a fleet env another uid can write; token never re-exported from it. Quick gate + jaahd suite green (4 pre-existing develop failures). Review lane pass. #7038 merged a48cc8f; its deploy superseded by a newer one. Memory: none applied.