http2: count a lost ping exactly once, and never on a failed connection

[ali-sayyah]

The health-check timer is re-armed after every ReadFrame return,
including the final erroring one, and no close path stops it: one
ReadIdleTimeout after every connection close a post-mortem health
check pings the dead connection, fails immediately, and reports a
spurious CountError("conn_close_lost_ping"). A genuinely lost ping is
counted twice: the real detection, then the post-close echo.

CL 198040 shipped the health check with the timer stopped when the
read loop exits; CL 572378, an unrelated test-infrastructure
conversion, dropped the stop with no behavioral rationale (v0.22.0
has it, v0.23.0 does not). Restore the stop, publish the read loop's
terminal exit under cc.mu before the failure is counted, and make
lost-ping classification a single-claim close: the eligibility check
and the claim share one critical section in closeForLostPing, so
overlapping health checks, or a ping racing the read loop's terminal
exit, can never produce a second count. The CountError callback runs
outside the lock. A ping that fails on a connection that is live at
claim time is still counted and still closes the connection,
preserving the write-blocked-ping detection of CL 354389.

This fixes the legacy transport, used on Go versions before 1.27 and
with the http2legacy build tag (go build -tags=http2legacy). The
default Go 1.27 path uses net/http's copy of this code, which has the
same defect and is fixed separately; that change closes the issue.

Updates golang/go#80920