docs: build the supported machines table from a device registry

[rickwierenga]

The supported machines page was a TODO, and the devices.json already in the repo was unused with paths that had gone stale during the documentation reorganisation. This replaces both with a registry that the docs render from.

What it is

docs/_static/devices.json lists every supported machine: vendor, model, device type, capabilities, support level, driver import path, and links to its documentation page, its source, the manufacturer, and the person who looks after it.

Two MyST directives read it:

• device-table — the searchable, filterable table. Used bare for the whole list on the supported machines page, and with :vendor: for a compact per-vendor list (see the BioShake notebook).
• device-card — one entry, for the top of a machine's own page.

Adding a machine is one JSON object. There is no table markup to keep in sync.

Validation

The registry is checked when the build starts, so metadata cannot drift away from the pages it describes:

• unknown fields, duplicate ids and unknown statuses fail the build
• kind and capabilities are controlled vocabularies; a term that nothing uses is also an error, so the lists cannot accumulate dead synonyms
• doc_slug and code_slug must resolve to a real page and a real module

docs/_exts/plr_devices/registry_tests.py covers the loader, the renderers and the registry itself. It depends only on the standard library, so it runs in every test environment rather than only where Sphinx is installed.

Registry contents

64 entries become 93. The BioShake, Cytomat, Thermoshake and Hamilton STAR families each had one row covering several machines; they are now one entry per model, with capabilities and support levels taken from the drivers. Ten entries whose factory raises NotImplementedError before constructing anything are marked WIP rather than Mostly — you cannot instantiate them, so none of their capabilities are available.

Every manufacturer link was checked by fetching it: 37 were wrong and are corrected, 4 pointed at pages that no longer exist and are removed. Notably, QuantStudio 5 pointed at the Human Identification forensic variant, and all twelve QInstruments models shared one generic landing page.

Known gaps

• mettler-toledo-wxs205sdu and agrowtek-pump-array links could not be fetch-confirmed — mt.com returns 406 to automated requests and agrowtek.com was unreachable. Both were left as they were.
• biotek-cytation-5 and biotek-synergy-ht may point at dead or redirecting pages, but agilent.com returns 403 to every request, so this could not be confirmed either way. Left in place rather than removed on unverified grounds.
• cole-parmer-masterflex points at Avantor because masterflex.com was returning HTTP 522 throughout; a first-party page may exist.
• A device-card in a notebook renders on the published page but shows as a literal code block when the notebook is opened in an editor. That is inherent to a build-time directive.

🤖 Generated with Claude Code