Close eight open SDK tasks: the pidfile, the log, cards, names and a live curve

Each was a loose end recorded under `### SDK` in the notepad.

`serve` takes its own pidfile down on SIGTERM. uvicorn restores the handler it
found and re-raises the signal it stopped on, so the default handler ended the
process without unwinding and the `finally` never ran — which is what a stop
sends, and what left `serve.pid` behind.

`serve.log` is cut back past 5 MB by the engine rather than by the screen that
started it, so an adopted engine is bounded too. Gated on its own stdout being
an appended regular file, which is what makes the cut safe: the kernel then
puts the next write at the new end.

Cards are counted from `/dev/nvidia[0-9]*`, so `FLOW_GPUS`/`--gpus` of 0 means
"work it out" the way `FLOW_CPUS` always has. The engine counts, not the
accountant — a remote worker builds one of those from its own inventory, and
detecting there would hand it the engine host's cards. The worker counts last:
what a batch job says it was granted still wins.

`GET /runs/metrics/names` is the distinct over a selection that `--list` and
the terminal's metric picker were approximating by reading the newest run that
had measured anything, which missed a name only an older run ever wrote.

`MetricSink` announces each batch it has written (`run_metric`, carrying the
names). Not a per-point event: one covers up to 500 points or two seconds of
them, and the rows stay the record. The terminal comparison fills in as the
first readings land instead of staying blank until reopened, and the browser
refetches the run and any comparison rather than the list behind them.

`retry --group` pages the list route by `before` instead of stopping at 500.

The terminal dashboard takes the terminal's colours (`ansi-dark`), and the web
UI can re-pair from Settings without disconnecting first.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PRQ9bmTvCbqCwXo9mxZzzV

docs/getting-started/data-science.md

@@ -298,10 +298,11 @@ nothing else is given that card while it runs.
 string whose contents depend on the version you have installed, so writing it
 for you would silently replace whatever you had put there.
 
-The engine has to be told how many cards it has (`fluksio serve --gpus 1`, or
-`FLOW_GPUS`) because detecting them would mean depending on a vendor's
-tooling. Until it is, a node asking for one is quietly given zero and runs
-alongside every other; the log says so the first time it happens.
+The engine counts NVIDIA's device nodes to find its cards, which asks no
+vendor tool. A card those do not cover has to be declared (`fluksio serve
+--gpus 1`, or `FLOW_GPUS`); until it is, a node asking for one is quietly
+given zero and runs alongside every other, and the log says so the first time
+it happens.
 
 Workers are kept warm on purpose, so a library that takes most of the card at
 import would hold it after the run finished. The workers that ran on a card
@@ -645,7 +646,7 @@ code digest beside it, so an exported file still says what produced its
 numbers. Numbers inside a record are columns of their own
 (`metric.final_metrics.train_loss`) and `--metrics` and `--params` take those
 dotted paths to narrow the table. Metric names are flow-qualified, so
-`--list` prints the ones a selection carries. `Client.export_metrics()` and
+`--list` prints every one a selection recorded. `Client.export_metrics()` and
 `Client.export_runs()` answer the same rows to a notebook, ready for
 `pandas.DataFrame`.