feat(site): show the vendor documents a driver was built from

[HuggeK]

upstream_docs landed in #48: the manifests record the vendor documents a
driver was decoded from, and a weekly workflow watches them. But the field
never reached the catalog page — the one artefact most people actually open.
The page named 80 drivers without once saying where any of them came from,
which is the question the field was added to answer.

Each declared document is now a link in the driver's card, under its title,
with the kind and what url_stability claims:

Vendor documents this driver was built from
NIBE S-series myUplink register/parameter changelog (nibe-n.pdf) ↗
CHANGELOG · URL STABLE IN PRACTICE

Watched weekly: when one of these changes or stops resolving, the repository
opens an issue to review the driver against it. A change is a prompt to look,
not evidence that this driver is wrong.

Two drivers declare documents today (nibe_local, myuplink); a driver with
none grows no empty heading.

Why the stability wording is spelled out instead of printed as the enum

url_stability describes whether the URL stays put, not whether the
registers behind it are settled. Printed bare next to a link, "stable" reads
as the second thing — which is the opposite of why the field exists, since a
watched document is watched precisely because its contents may move. So the
page renders stable as "URL stable in practice", committed as "Vendor
commits to this URL", and so on.

The accompanying note exists for the same reason: the watcher detects a
raw-byte change, which is a prompt to review, not proof a driver is wrong.

Why the generator re-checks the URL scheme

validate_manifest.py already holds upstream_docs[].url to http(s), and
it runs in CI. But it is a different tool run at a different time, and this
generator is where the value becomes an href a reader clicks — the one place
where trusting the input is not free. test_a_document_url_must_be_http
covers it.

How the rendering is tested, given the page renders in the browser

test_upstream_docs_reach_the_page would pass just as well if the payload
carried the documents and the card silently dropped them — which is precisely
the state before this change. So test_the_card_renders_the_documents_it_collects
asserts against driverCard's own source that it calls the builder.

Locally I also ran the page's actual shipped script under Node against a DOM
shim and asserted on the HTML it produces: both drivers' href, link text,
kind and stability line appear in the card, the link survives into the
whole-page render, and a driver with no documents grows no empty section.
That harness is a local check, not committed.

No manifest, driver or version changes: this only renders data already in the
repository, so nothing reaches the signed channel.

🤖 Generated with Claude Code