Tap-target check expects a pin button per WAN host row (closes #46)

The viewport harness's tap-target check required at least 10 visible
pin buttons while 26 render, so pin buttons missing from up to 16 rows
went unnoticed. It now expects one per WAN host row. The host row count
the harness gathers, which the app-rendered check also reads, counts
only the WAN host rows, since the local host rows have no pin button.
Each control's minimum is now worked out from the gathered facts.

TODO.md's harness entry no longer says every check guards itself: the
overflow, viewport-edge and clipped-text checks rely on app-rendered.

Model: opus-5-5

test/viewport/README.md

@@ -49,10 +49,11 @@ sizes straddling the breakpoint for the rotation case.
   excluded: it is a design choice, not breakage.
 - **tap-targets-44px** — every interactive control is at least 44x44 CSS px on
   touch viewports, _and_ each selector in the control list matched at least the
-  number of visible elements it declares. The second half is what stops the
-  check passing vacuously: with size alone, a renamed class would take its
-  controls out of the measured set and the check would report "all 0 controls
-  are at least 44x44" and pass. See below.
+  number of visible elements it declares: one of each single control, and one
+  pin button per WAN host row. The second half is what stops the check passing
+  vacuously: with size alone, a renamed class would take its controls out of the
+  measured set and the check would report "all 0 controls are at least 44x44"
+  and pass. See below.
 - **host-rows-stacked / host-rows-side-by-side** — the rows genuinely reflow.
   Computed `flex-direction` _and_ the actual geometry are checked, and in the
   narrow layout the info block and the sparkline must each occupy essentially