feat: work a backlog of items against the fleet - #205

Work a file of work items against the fleet, at the pace the fleet allows.

Summary

• Fleet files: nodes may carry tags (the operator's description of what
  work a node takes on) and the file may declare top-level concurrency
  limits — a total and per-tag ceilings on how much work is in flight
• Gateway: GET /v1/fleet serves the fleet's topology behind the caller
  token — every node's tags, state, and serving facts, the model a stopped
  node would start with where the fleet wakes, and the file's wake,
  ranking, and concurrency settings, each absent where the file declares
  it not
• spinloop orchestrator --gateway <address> --items <file>: reads the
  topology from the gateway, admits backlog items within the fleet's limits
  ranked by priority, and runs each admitted item as a one-shot agent
  (opencode or Pi) whose inference goes through the gateway; each item's
  state, its agent's output, and the file's lock are kept beside the items
  file
• Restart and interrupt behave: a clean interrupt stops the running agents
  and re-queues their items; an unclean death leaves items running and the
  next run records them failed rather than working them twice
• Harness Apply takes a setDefaultModel flag, so a dispatch that names
  its model itself leaves the harness's default model as it was
• In-process integration tests over a real gateway, a docker e2e scenario in
  the gateway example, and docs: a feature guide for working the items file
  plus the command reference

Implementation details

The orchestrator holds no fleet file and no node credentials — the gateway is
its only view of the fleet, and the only thing that can start a node. A
stopped node is offered to an item only where the fleet's wake policy allows,
and it is the gateway, for the item agent's first request, that does the
starting. This keeps the fleet file the single source of truth for the
topology and leaves waking where it already lives.

The items file's id is an item's identity for life: the state beside the
file keeps one record per id, so a finished item is never worked again —
new work gets a new id.