jobq: a job asks for the ids it wants back

The operator's instruction on the issue was "the closure returns an array
of guids, and enqueue_job returns the node ids in that order". What was
here instead returned a HashMap of everything inserted, and no caller used
the keys: submit dropped the return, insert_group did into_values(), and
the scheduler ignored what append_subgraph handed back. The guid-keyed
lookup was dead weight, and into_values() made that Vec arbitrarily
ordered -- harmless only because nothing read it.

insert_job now takes FnOnce(&JobBuilder) -> Vec<NodeGuid> and returns the
matching ids positionally. A handle from another job is UnknownNode rather
than a silent omission: the return is positional, so a short vector would
misalign every id after it.

c0re's Declare stays FnOnce(&Job) and the wrapper names no handles in one
place, rather than ending seven templates in an empty vector -- a DAG is
addressed by its container node, which submit inserts itself. That frees
insert_group from needing every id, so the node_rt pre-seeding goes too:
NodeRuntime is one Option field and every reader already tolerated a
missing entry (entry().or_default(), get().and_then(), iter().find()).

The tests are the argument for the shape: capturing a handle through a
mutable binding to look it up in the map afterwards collapses into
returning it and destructuring the result.

hive-jobq/README.md

@@ -16,8 +16,9 @@ kinds, wires deps, and supplies a runner; the scheduler decides what can start.
 ## Model
 
 One **persistent graph** for the whole system, not a DAG per job. Enqueuing
-inserts a self-contained sub-DAG and returns the new node ids; the scheduler
-runs a continuous loop, starting every node whose deps are satisfied:
+inserts a self-contained sub-DAG and returns the ids of the nodes the job
+*asked* for, in the order it named them; the scheduler runs a continuous loop,
+starting every node whose deps are satisfied:
 
 - **Resource deps** are named counting semaphores over a caller-chosen type `R`
   — e.g. `build-slot` (capacity N), `agent/<name>` (capacity 1), or any