feat(harness): auto-configure launches from --env alone - #202

spinloop harness --env <name> now configures and launches the harness from what is actually deployed to that environment when no Spinloop is applied, and its flag parsing no longer depends on argument order.

Summary

• Auto-configure from a deployed environment: spinloop harness --env <name> with no Spinloop applied fetches the environment's live deploy-config (runner, served model, context size — read from the same SSM state deploy already writes) and configures the harness from it, exactly as an equivalent Spinloop would. This means a second machine only needs the environment registered locally (remote.json), not a copy of the Spinloop that was deployed — and a later redeploy is picked up automatically on the next launch rather than requiring anyone to re-copy anything.
• An environment with nothing deployed, or whose env Lambda predates this change, fails the launch before writing any config, naming the fix (spinloop remote deploy ... --env <name>, or spinloop remote bootstrap to update the control plane).
• Applying a Spinloop alongside --env is unaffected — its PROVIDER/ALIAS/MODEL/CONTEXT still win over the environment's deploy-config.
• Fixes spinloop harness's flag parsing: previously, --env (and the command's other flags) had to appear before a leading Spinloop alias/path to be recognised — spinloop harness dev-3 --env dev-1 ... silently forwarded --env dev-1 to the harness instead of consuming it, with no error. Worse, an unrecognised flag (e.g. --prompt) appearing before the Spinloop name caused a hard unknown flag failure. Flags are now recognised wherever they sit relative to the Spinloop name.

Implementation details

• The env Lambda (remote/lambda/env/index.ts) now best-effort reads the environment's deploy-config from SSM (the same helper start/stats already use) and includes deployed/runner/modelId/servedName/contextSize in its reply when one is registered and parses; a missing or unparsable deploy-config just omits the fields rather than failing the call. Existing deployed accounts need spinloop remote bootstrap re-run to pick up the updated Lambda.
• cmd/spinloop/remote.go gains providerForRunner, the reverse of the existing runnerFor mapping (llamacpp/vllm are both identity mappings, so nothing else can ever reach a deploy-config).
• applyRoutedSpinloop gains an autoConfigure path that synthesises a spinloop.Selection from the fetched environment's deploy-config immediately before the existing applySelection call, so the auto-configured path and the Spinloop-driven path write config through the exact same code.
• The flag-parsing fix replaces harnessCmd's single fs.Parse call (which stopped recognising flags at the first positional, per SetInterspersed(false)) with a hand-rolled scanner (splitHarnessArgs) that recognises the command's own flags and at most one Spinloop-naming positional in any order, and treats the first genuinely unrecognised token as the start of the harness's own arguments rather than erroring.
• Full design rationale and spec deltas are in openspec/changes/harness-env-autoconfig/ (not yet archived).