e2e/qa: stop counting devices that cannot accept users as failures

[ben-dz]

Summary of Changes

Mainnet Beta QA failed 7 times over Aug 8-10; three of those (infra runs 31248009915, 31266248546, 31286128831) had one cause. qa_alldevices_unicast_test.go checks device readiness at five sites and logs Ignoring <x> failure for device not ready for users, but each site increments FailedTests before that check, so the carve-out only suppressed the log line while the device still counted as failed. laconic-dfw-sw01, laconic-mia-sw01 and laconic-was-sw01 have been activated with max_users=0 since Aug 6, and the CLI refuses those connects outright; cmh-mn-qa01 draws from a 13-device pool, so three unusable devices produced a 21-29% per-host rate against the 20% gate.

Gating the counter is not enough: Success() also requires PacketsSent > 0 && PacketsReceived > 0, which a device that never connected can never satisfy. So not-ready devices are excluded from ComputeFailureStats entirely — including from the per-host denominator — behind a new Device.Ready() that replaces the condition previously spelled out at six call sites.

That exclusion opens a fail-open path worth reviewing closely: with every device excluded, totalDevices is 0, the overall rate is NaN, and NaN > threshold is false, so a run that tested nothing would pass. Devices are created with max_users=0 until activation unlocks them, so a new or metro-drained fleet lands exactly there. The rate math is now guarded by a t.Fatalf, and FailureStats.Skipped carries the excluded codes into test output so "3 devices skipped" is distinguishable from "3 devices tested and fine".

Separately, client_unicast.go wrapped an always-nil lastErr — the retry loop returns early on any error — so every connectivity failure this weekend read failed to ping after 3 retries: %!w(<nil>). It now reports packet counts.

Ready() is a deliberate subset of the program's is_device_eligible_for_provisioning: a device at users_count + reserved_seats >= max_users hits the same CLI rejection and still counts as a failure. That is the same class of false red one field over, but fixing it means re-adding the capacity check #3697 removed, so it is left as a follow-up. MaxUnicastUsers is not consulted — 0 there means "no per-type limit", the inverse of drained.

Testing Verification

go test ./e2e/internal/qa/... and golangci-lint run --build-tags=qa ./e2e/... (0 issues) pass. The four new TestComputeFailureStats subtests were confirmed to fail against the unfixed aggregation and pass after; without the fix the mainnet shape reports total=6 failed=3 where it should report total=3 failed=0. TestPingFailureError asserts the message carries packet counts and never renders %!w. Existing fixtures in that file had zero-valued Status/MaxUsers and so were not Ready(); they are now explicitly activated, which is why the diff touches subtests it does not otherwise change.

Not verified: the qa-tagged e2e tests need live fleet access and cannot run here, so the change is unexercised against the real fleet. TestQAAgentConnectivity/Ping fails in this container for lack of raw-socket privileges, on main as well as this branch.

A reviewer also flagged that a not-ready device still consumes a batch host slot, and on the two-host devnet run that can trip the existing fewer than 2 clients connected fatal regardless of this fix. That predates this change and did not fire in any weekend run; filing separately rather than widening this diff.