feat(ci): sprawdzaj czy strony producentow istnieja, i mow gdy nie da sie stwierdzic - #273

… cannot tell

Every row in data/devices.json is worth citing because a vendor page stands
behind it. When one of those pages moves, the row goes on asserting something
with nothing holding it up, and nobody finds out until a reader clicks. Twenty
rows, seventeen external links, and nothing was testing them - the monthly
review listed them for a human to click.

Whether a page still exists is a fact, so it gets checked. Whether an advisory
changed in a way that matters is a judgement, so it stays with a person. The
existing note in this workflow already drew that line and this stays on the
same side of it.

The implementation has three outcomes rather than two, and the third is the
one that makes it usable. 404 and 410 are the vendor saying the page is gone:
definite, flagged loudly, and the row has lost its evidence. Everything else -
a timeout, a 403, a refused connection - means we could not reach the page from
a data centre, which is a different statement entirely.

That distinction is not theoretical. support.hp.com answered 200 by hand this
morning and refused a connection an hour later from the same machine; several
of these vendors rate-limit or block non-residential addresses. A first draft
of this check flagged all sixteen links as broken, which was the network and
not the vendors.

Shipping that version would have produced a monthly checklist full of alarms
that are not real, and a checklist that cries wolf stops being read - which
costs more than the check was ever worth. The unverified case is therefore
worded as a note that the check could not be taken, which is the same rule this
project applies to every other measurement it cannot make.