feat(#550): add depends_on to queue entries for explicit dep tracking

docs/coordinator.md

@@ -74,6 +74,28 @@ as it progresses through lifecycle phases (`"nix build"`, `"nixos-container stop
 `/api/state` and renders the current step beneath the running entry so the operator
 can see which phase is taking time.
 
+### Dependency tracking
+
+Each entry carries a `depends_on: Vec<u64>` field. The worker skips entries whose
+dependencies are not yet resolved — a dependency is resolved when its id is either
+in the queue as a terminal entry (`Done` / `Failed` / `Cancelled`) or no longer in
+the queue at all (evicted by `trim_history`, which only evicts terminals).
+
+Use cases:
+- Chain a `Rebuild` after an explicit prerequisite step without coupling them through
+  the `parent_id` cascade mechanism.
+- Sequence a `PermChange` + `Rebuild` pair where the rebuild must not start until the
+  perm-file write commits (already handled by the single-worker FIFO today, but
+  `depends_on` allows explicit cross-kind sequencing when parallel workers are added).
+
+`depends_on` is part of the dedup key: two entries with the same `(kind, agent,
+parent_id, inputs, approval_id)` but different dep sets are treated as distinct work.
+
+**Worker re-notification**: the worker drains `take_next()` in a tight loop after
+each entry finishes. When a dep entry transitions to terminal, the loop re-evaluates
+the queue immediately, so downstream entries are unblocked with no extra wakeup. No
+additional `notify_one()` call is needed.
+
 ---
 
 ## Container view