An unmeasurable backup must not hide a working one

CI caught this: judging a host by its stalest kind treated a never-confirmed
revision (lastseenat NULL) as the worst case, so it won. The verdict for a NULL
confirmation is tri-state None, which renders as NO BADGE - so a host with a
healthy ntlars backup and one backfilled row showed nothing at all. Hiding a
working backup is the one thing that badge must never do.

A NULL confirmation is not stale, it is unmeasurable. The stalest kind is now
chosen among kinds that can actually be judged, which is the rule staleness.py
already applies: a chain becomes measurable the first time its PC posts and says
nothing until then. If every kind is unmeasurable the host still reports which
kind it has, with a None verdict and no badge.

The test that caught it pinned the old newest-wins behaviour, which part markers
made wrong; it now pins stalest-measurable-wins and keeps its NULL clause, which
was right all along and is what found the bug.

Also worth recording how it was missed: the change was verified against
test_geenforce_reporting.py and test_backups.py, and this assertion lives in
test_geenforce_publish_gate.py, which was never run.

tests/test_plugins/test_geenforce_publish_gate.py

@@ -155,9 +155,20 @@ def test_hosts_below_libversion_reports_the_floor(db):
 
 # -- backup state on the reports table ---------------------------------------
 
-def test_backup_state_prefers_the_newest_confirmed_revision(db):
-    """A host with several revisions shows the most recently CONFIRMED one, and
-    a revision that has never been confirmed (lastseenat NULL) never wins.
+def test_backup_state_reports_the_stalest_measurable_kind(db):
+    """A host is judged by the WORST backup it has, not the best.
+
+    This used to prefer the most recently confirmed revision. That was right
+    while a PC reported one kind, and became wrong when part markers arrived: a
+    marker bay reports ntlars AND partmarker, so a daily ntlars post kept the
+    badge green while the marker backup had been failing for a month. A host is
+    healthy only when everything it backs up is current, and the badge names the
+    kind that is not.
+
+    A revision that has never been confirmed (lastseenat NULL) still never wins.
+    It is not stale, it is unmeasurable - and letting it win hid a working
+    backup entirely, because the verdict for a NULL confirmation is tri-state
+    None, which renders as no badge at all.
 
     Ordering happens in Python on purpose. Doing it in SQL needs
     ORDER BY ... NULLS LAST, which SQLite accepts and MySQL rejects outright -
@@ -191,7 +202,10 @@ def test_backup_state_prefers_the_newest_confirmed_revision(db):
     facts = {'wjpc01': {'backupkind': None, 'backuplastseen': None}}
     _attach_backup_state(facts, {'WJPC01'})
 
-    assert facts['wjpc01']['backupkind'] == 'udc'
+    # ntlars is 9 days old, udc was confirmed just now: the host is judged by
+    # ntlars, and the badge names it so somebody knows WHICH backup stopped.
+    assert facts['wjpc01']['backupkind'] == 'ntlars'
+    # 'files' has never been confirmed, so it neither wins nor blanks the badge.
     assert facts['wjpc01']['backuplastseen'] is not None