docs: update spawn flow docs for apply_commit handling first spawn (follow-up to 66f1568)

docs/approvals.md

@@ -42,19 +42,15 @@ happens after a decision lands.
    ApplyCommit kind) land in the manager's inbox, carrying both
    the canonical sha and the terminal tag.
 
-`Spawn` approvals follow the same shape but skip the commit-diff
-step — the operator just sees the name. On approve, hive-c0re
-creates the container in a background task while the dashboard
-shows a spinner.
-
 `InitConfig` approvals are the first step in a two-step spawn
 flow. On approve, hive-c0re seeds the proposed config repo with
 a default `agent.nix` template and sends the manager
 `HelperEvent::ConfigReady { agent }`. The manager then reviews,
-edits, and commits the template before calling `request_spawn`
-to proceed to a Spawn approval. This gives the manager (and
-operator) an explicit review gate on the initial configuration
-before any container is created.
+edits, and commits the template before calling `request_apply_commit`
+to proceed to an `ApplyCommit` approval. The first `ApplyCommit`
+creates the container; subsequent ones rebuild it with new config.
+This gives the manager (and operator) an explicit review gate on the
+initial configuration before any container is created.
 
 ## Meta flake
 
@@ -333,8 +329,8 @@ regular claude turn so the manager can react. Variants
 - `ApprovalResolved { id, agent, commit_ref, status, note }` —
   fired by `actions::approve` + `actions::deny` whenever an
   approval transitions to its terminal state.
-- `Spawned { agent, ok, note }` — `actions::approve` (Spawn-kind)
-  + admin `HostRequest::Spawn`.
+- `Spawned { agent, ok, note }` — `actions::approve` (first-time
+  ApplyCommit-kind) + admin `HostRequest::Spawn` (deprecated).
 - `Rebuilt { agent, ok, note }` — `auto_update::rebuild_agent`
   (covers startup scan + manual `/rebuild` from dashboard) +
   `actions::approve` (ApplyCommit).
@@ -353,7 +349,8 @@ regular claude turn so the manager can react. Variants
 - `ConfigReady { agent }` — a new agent's proposed config repo was
   just seeded (post-`InitConfig` approval). The manager can now
   edit `/agents/<agent>/config/agent.nix`, commit the changes,
-  and submit `request_spawn` to create the container.
+  and submit `request_apply_commit` with the commit sha to create
+  the container (first ApplyCommit also triggers spawn bookkeeping).
 - `NeedsUpdate { agent }` — sub-agent's recorded flake rev is
   stale. Manager calls `update(name)` to rebuild — idempotent,
   no approval required.