fix(asio): order the read handoff so a completed read cannot be missed - #871

A connection could stop receiving while staying open, answering nothing until
the peer's own timeout gave up on it. Caught on arm64 with a read-path trace:

  handleRead(10)[c=10 p=0]   <- ASIO thread: content set, pending cleared
  block(8)     [c=10 p=1]    <- main thread: new content, stale flag

HandleRead publishes a completed read by writing the buffer contents and then
clearing m_readPending, and Read() consults that flag to decide whether a
background read is still outstanding. Both were plain members written on the
ASIO thread and read on the main thread, so nothing required the two stores to
become visible in that order. Where they arrive out of order the main thread
sees the new content with the flag still set, takes the "still running" branch,
and returns without serving data already sitting in the buffer -- and without
arming another read or posting an event.

That branch is reached from an event which has by then been consumed, so
nothing looks again. Both callers of PostReadEvent are unreachable: no read is
pending to complete, and Read is only entered from an event. The socket is
finished while remaining perfectly healthy at the TCP layer.

Making m_readPending atomic with release/acquire is enough. HandleRead already
writes the buffer before clearing it, so a reader that acquire-loads false is
guaranteed the buffer state that preceded it; the content, pointer and blocking
flag need no change. Its neighbours on the write path are already atomic with
comments saying they are shared across those same two threads, which is what
makes the read side look like an oversight rather than a decision.

Observed against a daemon over EC, where a stalled connection is visible as a
frozen client, but the members belong to the shared TCP socket implementation
and every connection uses them. The UDP path has its own implementation and
does not share these members.