Shared API key in fleet.yaml; remotes should accept an externally provided API key

[outofcoffee]

Problem

A remote endpoint's API key is always minted by the control plane: at deploy, ensureEnvApiKey creates cloud-vm-llm/<env>/api-key in Secrets Manager with a random value, and there is no way to say what the key should be. Every remote environment gets its own key, so a user cannot share one key across several remotes or reuse a key they already manage elsewhere.

fleet.yaml already knows how to name the key a daemon node's engine needs: a node's engineTokenEnv is an environment-variable reference — the file holds names, never secrets — resolved from the process environment first, then the .env beside the file, and the value is pushed to the node and injected into the launched harness. But there is nothing fleet-wide, and nothing for remotes: each remote mints its own key regardless.

Once remote environments are first-class fleet nodes (#99), a fleet.yaml that lists several remotes is the natural place to say "these endpoints all take this key". Today that is not expressible: an agent pointed at several endpoints needs a different key per endpoint, and there is no single shared key to give it.

Proposal

1. A shared API key in fleet.yaml. A fleet-level field (e.g. api-key-env: SHARED_KEY) naming the environment variable that holds the API key shared by the fleet's remotes. Same discipline as every other secret reference in the file: the variable's name, never the value; resolved from the process environment first, then the .env beside the file; unset is a configuration error naming the variable. A node's own engineTokenEnv stays a per-node override.

2. Remotes accept an externally provided API key. outfit remote deploy takes a caller-supplied key (flag, or the fleet file's shared reference when the node comes from a fleet) and passes it to the deploy Lambda. The control plane stores it in the environment's existing Secrets Manager secret — created if absent, set when supplied — instead of always generating one. Everything downstream is unchanged: the instance reads the same secret at boot, the env/start Lambdas still report it, and outfit harness injects it at launch exactly as today.

Decisions to make

• Rotation: deploying with a different key replaces the environment's secret, instantly invalidating the old one; deploying with no key leaves the existing secret alone (never regenerated). Both need to be explicit and documented, because an agent holding the retired key otherwise gets silent 401s.
• Where the key travels: the SigV4-signed deploy body (the payload is already hashed into the signature) and Secrets Manager, and nowhere else — not in remote.json, not in the fleet file, not in any reply.
• Relationship to Unify the remote and fleet clients behind one node driver #99: complementary rather than dependent. Deploy-time external keys stand on their own; the fleet-wide fleet.yaml key pays off once remotes are fleet nodes.