hive-runtime: read the ACP provider key from bao

An opencode ACP agent got its provider API key only from the hand-placed
backendEnvironmentFile. It now also reads it from the swarm secret store
at swarm/agents/<agent>/acp-provider, field api_key, under its own
certificate, and sets it in the spawned ACP agent's environment only.
Nothing is written to disk.

Precedence: a value already in the process environment (the env file)
wins and the store is not asked. Otherwise the stored key is used when
present. With no store, nothing stored, or a failed read, the agent is
spawned without the key as before, and one line is logged without the
value.

The variable name comes from the existing per-agent option
acp.opencode.provider.apiKeyEnv, exported as HIVE_ACP_API_KEY_ENV on the
harness only for the opencode preset. Other ACP commands are unchanged.

The read lives in hive-runtime, where the ACP child is spawned, so both
hive-agent and hive-subagent-daemon use it. The subagent daemon unit
gets the key name and, when the agent has a store, the agent's store
identity (the same credentials queue-identity.nix gives the harness).

No new option or setting. Closes #4841.

docs/tools/subagent.md

@@ -299,7 +299,10 @@ page applies as written.
 On `acp`:
 
 - each run spawns its own copy of the parent's ACP agent, which exits
-  when the run ends. The unit loads `backendEnvironmentFile` for it.
+  when the run ends. The unit loads `backendEnvironmentFile` for it. On the
+  `opencode` preset, the daemon reads a provider key that file leaves unset
+  from the swarm secret store at `swarm/agents/<agent>/acp-provider`, as the
+  harness does.
 - the session id lives in `subagent-acp-session-<name>` under the harness
   dir. `start` moves an old one aside, `continue` loads it into a fresh
   agent process, and a `continue` with none recorded fails straight away.