bitsocial logs -f doesn't see appended lines on Windows

[Rinse12]

Bug

On Windows, bitsocial logs -f (follow mode) does not emit new lines that another process appends to the current log file. The CLI emits the initial dump and then sits silent, even after the file size visibly grows.

Linux and macOS behave correctly.

Repro / evidence

The test continues watching old file if no new file appears (test/cli/logs.test.ts:462) reliably fails on Windows in CI:

• Run 26140177410 (2026-05-20): https://github.com/bitsocialnet/bitsocial-cli/actions/runs/26140177410/job/76883884390
• Run 25375977963 (2026-05-05): same assertion, same test.

The assertion:

expected '[2026-05-01T00:00:00.000Z] initial li…' to contain 'APPENDED_LINE'

The test:

1. Writes an initial line to a log file.
2. Spawns bitsocial logs -f against it.
3. After observing the initial line on stdout, appends APPENDED_LINE to the same file.
4. Expects the CLI to emit APPENDED_LINE within 8 seconds.

On Windows the CLI runs the full 8s without emitting the appended line. Linux and macOS pass.

Root cause

src/cli/commands/logs.ts uses fs.watchFile(currentLogFile, { interval: 300 }, readNewData) to detect new bytes. fs.watchFile is backed by libuv's uv_fs_poll_t. On Windows, this notification mechanism does not reliably fire when another process appends to a file — a long-standing platform gap, documented in nodejs/node#36888 and the original nodejs/node-v0.x-archive#1358.

This is not just a test bug: any Windows user running bitsocial logs -f against a running daemon log file would see the same silence.

Fix

Replace fs.watchFile with a userspace self-rescheduling setTimeout poll that calls fs.promises.stat() + reads new bytes when the size grows. This is the pattern used by production tail-f libraries (@logdna/tail-file, etc.) precisely because OS file-watcher events aren't cross-platform reliable for this scenario. CPU/IO profile is equivalent to the current setup (we were already polling — just inside libuv).

No new dependency; isolated change to src/cli/commands/logs.ts. The existing failing test serves as the regression test.

[Rinse12]

Reopening — the fix in #41 (76213c3) replaced fs.watchFile with userspace polling, but kept the fsPromise.stat(file).size > position gate before reading new bytes. CI run 26143373669 on windows-latest shows the same assertion failure (test/cli/logs.test.ts:462 — APPENDED_LINE never observed).

Root cause (revised): on Windows + NTFS, fs.promises.stat() returns a stale file size for a short window after another process appends. Because the read is gated behind size > position, the new bytes are never read.

The fix is to drop the stat gate entirely: open the file each poll and read() from position directly into a fixed-size buffer in a loop until read() returns 0 bytes. The kernel sees the true file end at read time, so this doesn't depend on metadata being fresh.