[outofcoffee]

Why

--env implied environment variables, but the domain word has always been node — a fleet node to pin a launch or a drive to, or a registered cloud environment when no fleet is in force. Align the external flag with the internal vocabulary.

Closes #236.

What changes

• The launch's two target flags — the fleet-pin --node and the renamed --env — merge into one -n/--node: a fleet node with a fleet in force, a registered environment otherwise.
• --env is removed outright, no compatibility alias. splitHarnessArgs catches a forwarded --env/-e on the launch and names the new spelling.
• Beside a fleet.yaml discovered in the working directory, --node now narrows reads and drives to that node rather than being refused. Only a --fleet flag beside --node is refused as "two answers to one target". On fleet start/stop that narrowing alone selects the node, standing in for the positional name.
• -n is the short form everywhere except fleet deploy and cloud deploy, where -n stays --dry-run and the node is named long-form only.
• Genuinely environmental spellings are untouched: the ENV instruction, .env files, --print-env, --token-env, and the cloud env command (only its target flag becomes --node).

Notes

• Internal cloud package vocabulary (Environment, the clouds/<name>/cloud.json registry, the AWS env wire param) is deliberately not renamed — this is CLI surface only.
• Specs updated under openspec/changes/rename-env-flag-to-node/; docs and examples updated to the new target semantics.
• Verified end-to-end with stub daemons: pinned launch carries the node's endpoint and hands its engine key to the harness through the environment (never to disk); narrowing, the discovered-fleet fallback, and fleet start -n all exercised.

#236