Say at startup when a flow wants a card, and record one seed rather than two

Three things the first pass left.

`serve` now names the flows asking for a GPU when the engine has none
declared. The placer already warned, but into the log, where a fresh install
that forgot `--gpus` does not read it — and the cost of missing it is GPU
nodes running concurrently, which is what the declaration exists to prevent.

The seed was the one field an export still had to coalesce: `--seed 1`
filled the run-level column and left `param.seed` blank, while a declared
seed filled the parameter and left the column blank. It is resolved like
every other input now, and the column carries the seed the run actually used
however it arrived — including when a parameter outranks the run's own,
where the column used to report the one that lost.

And the docs say plainly that declaring the card is what buys the worker
retirement: a node that imports jax without `resources={"gpus": 1}` never
gets CUDA_VISIBLE_DEVICES, so nothing marks its worker as one holding a card.

docs/getting-started/data-science.md

@@ -309,6 +309,12 @@ import would hold it after the run finished. The workers that ran on a card
 are retired when the run ends, which gives the memory back; what it costs is
 the next GPU run paying for its imports again.
 
+**The declaration is what buys that**, not touching the card. A node that
+imports jax without `resources={"gpus": 1}` runs on the shared pool, is never
+given `CUDA_VISIBLE_DEVICES`, and leaves a warm worker holding whatever it
+preallocated. Declaring the card is what makes it a worker the engine knows
+to retire — and what stops two such nodes running at once in the first place.
+
 Declaring nothing is the default and is right for most nodes — a poll, a
 threshold, a message on its way somewhere. Those share the engine's worker pool
 and are given a fair share of `FLOW_CPUS` as a thread cap, which is what stops