feat(remote): require a named environment, drop the implicit default

[outofcoffee]

Removes the environment a remote command falls back to when none is named — and, with it, the legacy config path that was the reason resolving an environment name had a special case.

Summary

• BREAKING Every remote subcommand requires --env <name>. A command given none fails naming the flag and listing the registered environments, rather than acting on one the user did not choose.
• BREAKING default loses its special status. The name stays legal and resolves like any other; it is simply never assumed.
• BREAKING ~/.config/spinloop/remote.json is no longer read. LoadDefault, LoadConfig and ConfigPath are deleted.
• The documented no-remote.json workflow keeps working and starts carrying an identifier: where --env <name> names an environment with no file, complete SPINLOOP_REMOTE_* overrides configure it and the name given becomes the environment identifier.
• internal/fleet resolves a kind: remote node the one way everything else does — no default-environment special case.

Implementation details

The danger was already on record. remote deploy has required --env since the REMOTE-keyword removal, whose design says why: "Creating an environment binds a name to a machine; a silent default would hide that binding and risk clobbering the default environment" — rejecting an optional flag as a footgun. That applies to stopping an instance as much as deploying one; it had simply been applied to one command. Five others (start, stop, pause, restart, keep) still changed instance state with no target named.

A latent bug this fixes rather than deepens. docs/env-vars.md documents running the remote commands with no remote.json at all, configured entirely by SPINLOOP_REMOTE_*. But Config.Environment is set only by unmarshalling a file, and that field's own comment says the shared Lambdas "reject a call without one" — so that path reached the control plane with no identifier. Requiring the flag supplies exactly the missing piece: --env ci with complete overrides now works properly, where before it was quietly broken. That is why option 3 (no implicit target at all) ends up more capable than the narrower fixes, not merely stricter.

Two decisions worth a look, recorded in the design:

• D1 — required on reads too, not only the mutating commands. A narrower change could require it just for start/stop/pause/restart/keep. Rejected: a rule with an exception list is one an operator has to remember, and the read is the rehearsal for the write — someone who runs remote status then remote stop in the same shell should not find the second means something the first did not warn about.
• D2 — default stays a legal name. The risk was never the string, it was commands assuming it. So --env default keeps working for anyone who has one.

Explicit non-goal: no stored "current environment" to make the flag optional again. That is the implicit target under another name. A shell alias or a fleet file does the job without the CLI holding hidden state.

The failure reads:

$ spinloop remote stop
Error: no environment named: pass --env <name> (registered: dev-1, dev-2, vllm-1)

$ spinloop remote stop   # nothing registered
Error: no environment named: pass --env <name> (none registered yet — `spinloop remote deploy --env <name>` creates one)

Coverage 90.5%, unchanged.