SPIKE ep0 connections: the leak is felhom-agent's, not the poll rate

R-341's first dated check, taken at +46.2 h: fd 17 -> 405 over 166,251 s
= 201.6/day. Pre-registered range was 370-450; observed 388. UNCHANGED,
as predicted. CLOSE-WAIT is 0 -- absent entirely, not merely flat.

Q1: exactly two peers, 194 each, no third party.
Q2: outcome (a). ep0 388 = 194 + 194 on the boxes, twice, and the four
    new sockets carry the same source ports on both sides. 0 closed in 31 min.

The finding: all 388 are held by felhom-agent. pvestatd and
proxmox-backup-client made 162,404 requests and leaked zero. Mechanism is
a per-cycle http.Transport with a zero-value IdleConnTimeout that nothing
ever closes (internal/pbs/client.go:56, main.go:1486). R-336's premise
does not survive this -- cutting the poll rate would have fixed nothing.

Q3 NOT measured: Phase C held at STOP 1, prediction pre-registered first.

Part 0 captures the due-checks gate's first conviction on a real overdue
date (rc=1, names R-341, sole failure among 10 gates). Row cleared at
Part 4, after the result was recorded in R-341, not to make a push work.

New: R-344 (the transport leak), R-345 (hub/Makefile pushes :latest),
R-346 (ActiveEnterTimestamp reads 5h56m early -- NRestarts is still 0).

STATUS.md

@@ -1,7 +1,7 @@
 # STATUS — what works, what's broken, what's next
 
-**Updated 2026-08-18 (afternoon — a listening socket that served nobody, a rehearsal upgrade that changed
-nothing, and a new install that is finally current).**
+**Updated 2026-08-20 (morning — we looked at who was actually holding the off-site box's connections
+open, and it turned out to be us).**
 
 > **A view, not a source.** `documentation/backlog/OPEN-ITEMS.md` is the authority; this page restates
 > part of it in plain words, and **nothing may exist only here**. **Items, not paragraphs. One screen.**
@@ -116,6 +116,14 @@ record with no machine** — created 13 August, no host, no backups, nothing to
   alarm. **Corrected later the same morning: my first estimate of how fast it leaks was too
   optimistic by about 2.5×** — measured properly it is under a year to the new ceiling, not two years.
   A deadline, not a comfort.
+- **The leak is OURS, not Proxmox's, and asking fewer questions would not have fixed it** (R-344, found
+  2026-08-20). We finally looked at who was on the other end of the stuck connections. Every single one
+  belongs to **our own agent** on the two demo machines — it opens a connection to the off-site box on
+  each 15-minute cycle and never closes it, and neither does the box. The two Proxmox pollers that make
+  99.5% of the traffic leak **nothing at all**. So the plan recorded under R-336 — turn the question
+  rate down, then watch the count stop climbing — **would have changed nothing and looked like a failed
+  fix.** The count still says about a year to the ceiling. **Nothing is broken today**; this is a
+  deadline we now know where to aim at. *(register: R-344, and R-336 re-ranked)*
 - **The off-site box was updated, and it did not help — as expected** (R-341). On your ruling we
   installed the newer backup software for the practice, having first read its release notes and found
   **nothing** about the fault we have. The update went cleanly and everything works, but the leak
@@ -155,7 +163,9 @@ record with no machine** — created 13 August, no host, no backups, nothing to
 
 ## Working on next
 
-`demo-hp` is yours this evening — **this session did not touch it**. After that: the three remaining
+**One decision is waiting for you, at the top of `REPORT-spike-ep0-connections.md`:** whether to run the
+overnight measurement window on `demo-hp` tonight, and which of two versions of it. Nothing was changed on
+any machine in this session — every reading was read-only. After that: the three remaining
 R-264 readers, now that one has been built and we know what one costs; R-317 (one line in the agent);
 R-327 (decide what the naming claim's status should be); then the 2026-08-09 batch (R-279 … R-292),
 still untriaged against everything since.