A supply nobody could read is unknown, not empty

Reported as "CSF04 now reports all 0%", on the printer's own page as well as
the reports. Every supply on one host reading zero at the same instant is not
what a set of cartridges does; it is what a host that stopped answering looks
like.

getsuppliesbyip turned every unreadable item into 0:

    try:
        level = int(float(item.get("lastvalue", 0)))
    except (ValueError, TypeError):
        level = 0

An item that has never collected returns lastvalue as an EMPTY STRING, so
float('') raised and the handler substituted zero. lastclock was fetched in the
same request and read by nothing at all, so a reading from three weeks ago was
presented as current.

Zero is a legitimate level meaning spent, which is what made the substitution
dangerous rather than merely wrong. Downstream it reached `level <=
EMPTY_LEVEL`, which set daysleft to 0, which put the printer on the order list:
the report asked purchasing to buy a full set of cartridges for a printer
nobody had measured. On a waste container it was worse - waste is scored as
100 - level, so an unreadable one read as 100% full, the alarm state.

_readlevel now returns (level, lastseen) with level None for no usable reading:
empty, missing or unparseable lastvalue, or a lastclock older than 24h. A
lastclock that is absent is not treated as stale - a reading that cannot be
aged is not thereby wrong, and discarding it would lose real levels. A genuine
"0" is still 0, which is the half that keeps an actually-empty cartridge on the
order list.

classifysupply gains an 'unknown' status with remaining None. It is not
critical: critical is a claim someone acts on, and it may not be made about a
supply nobody measured.

The low-supplies report skips unknown rather than listing it as needing
replacement, and counts it in summary.unknown - a printer that has gone quiet
should be visible as that, not absent and not masquerading as empty.
_annotate_supply reads .get('level') with no 0 default, which would have put
the whole bug back.

PrinterDetail already rendered `level !== null ? ... : 'N/A'`, so it starts
telling the truth as soon as the backend sends null; the UI had been written
for a case the service never produced. It gains the unknown style - muted, not
a severity colour - and a tooltip separating "no reading at all" from "no
reading since <date>", which are different faults with different fixes.

Alerts needed no change: float(None) raises and that loop already continues,
so unknown supplies stop firing low-toner emails as a consequence.

12 of the 16 new tests fail on the old code. The 4 that pass either way pin
that real zeros still behave, which is the regression this fix could cause.

Not verified against CSF04's actual Zabbix data - dev has no reachable Zabbix.
This fixes the mechanism that turns unknown into 0%; /api/printers/<id>/supplies
now distinguishes them, with null for no reading and 0 for a measured zero.

plugins/printers/frontend/views/PrinterDetail.vue

@@ -215,8 +215,14 @@
           <div v-for="supply in supplies" :key="supply.itemid || supply.name" class="supply-item">
             <div class="supply-header">
               <span class="supply-name">{{ supply.name }}</span>
-              <span class="supply-level" :class="supply.status">
-                {{ supply.level !== null ? `${supply.level}%` : 'N/A' }}
+              <!-- N/A is not the same as 0%. A supply Zabbix has no usable
+                   reading for arrives with level null and status 'unknown';
+                   the title says which of the two reasons it is, because
+                   "no data" and "last seen three weeks ago" need different
+                   people to fix them. -->
+              <span class="supply-level" :class="supply.status"
+                    :title="supply.status === 'unknown' ? unknownReason(supply) : null">
+                {{ supply.level !== null && supply.level !== undefined ? `${supply.level}%` : 'N/A' }}
               </span>
             </div>
             <div class="supply-bar">
@@ -227,7 +233,7 @@
               ></div>
             </div>
             <div class="supply-meta">
-              <span>{{ formatSupplyType(supply.supplytype) }}<template v-if="supply.iswaste"> ({{ supply.remaining }}% remaining)</template></span>
+              <span>{{ formatSupplyType(supply.supplytype) }}<template v-if="supply.iswaste && supply.remaining !== null"> ({{ supply.remaining }}% remaining)</template></span>
               <span v-if="supply.partnumbers && supply.partnumbers.length" class="supply-parts">
                 <span
                   v-for="part in supply.partnumbers"
@@ -363,6 +369,15 @@ function formatSupplyType(supplytype) {
   return supplytype.charAt(0).toUpperCase() + supplytype.slice(1)
 }
 
+// Why a supply reads N/A. lastseen is the epoch of the newest reading Zabbix
+// holds: absent means the item has never collected, present means it has but
+// the reading is too old to present as current. Those are different faults and
+// the tooltip is the only place either one is stated.
+function unknownReason(supply) {
+  if (!supply.lastseen) return 'Zabbix has no reading for this supply'
+  return `No reading since ${new Date(supply.lastseen * 1000).toLocaleString()}`
+}
+
 function formatDate(dateStr) {
   if (!dateStr) return '-'
   return new Date(dateStr).toLocaleString()
@@ -414,6 +429,10 @@ function formatDate(dateStr) {
 .supply-level.ok { color: var(--success); }
 .supply-level.low { color: var(--warning); }
 .supply-level.critical { color: var(--danger); }
+/* Muted on purpose. An unknown level is not a severity - colouring it like one
+   would put it in the same reading as critical, which is the confusion this
+   whole change exists to end. The help cursor points at the tooltip. */
+.supply-level.unknown { color: var(--text-light); cursor: help; }
 
 .supply-bar {
   height: 10px;