fix: stop estale reopen loop from spinning

[dennisme]

Fixes #505.

When a log on an NFS/EFS mount is rotated, reads on the open descriptor
return ESTALE. The file stream handles that by reopening, but it reopens
immediately: unlike every other path in the read loop, the ESTALE path
never waits on the waker. On a mount where the reopened file is stale as
well, the stream reopens as fast as the kernel will let it, which burns a
core and fills the log with

read /logs/app.log: stale NFS file handle

until the mount recovers. Every turn of that loop also leaks a wakeup-less
goroutine handoff and bumps log_opens_total.

This change waits for the next wakeup before reopening, so a stale mount
costs one read per poll interval instead of a busy loop.

Two related problems in the same path:

• If the reopen itself failed, the stream returned without closing its
  lines channel. The Tailer only drops a source when that channel
  closes, so the pathname stayed in its map, TailPath kept returning
  early with "already got a logstream", and the log was never tailed
  again. The stream now closes the channel when it gives up, and the
  Tailer picks the file up again on the next pattern poll.

• The reopen passed the caller's os.FileInfo down to the new stream, so
  the new stream compared the file it was reading against a FileInfo
  from a file it had never opened, and spawned another stream at the
  first EOF. stream() now stats its own descriptor, and the FileInfo
  parameter is gone from stream() and newFileStream().

Tests inject ESTALE through a seam on the file stream's reader, because a
local filesystem won't produce it on demand. They cover both the read rate
across wakeups and the channel close after a failed reopen; both fail
against the current code.

w/ help from Claude

[google-cla]

Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

View this failed invocation of the CLA check for more information.

For the most up to date status, view the checks section at the bottom of the pull request.