fix(filesystem): use StringDecoder for UTF-8 safe headFile/tailFile

[re2zero]

Closes #4666

Problem

headFile() and tailFile() read files in 1024-byte chunks and call .toString('utf-8') on each chunk independently. When a multi-byte UTF-8 character (e.g. CJK characters, which are 3 bytes) straddles a chunk boundary, the split decoding produces mojibike (U+FFFD replacement characters).

Fix

Replace per-chunk .toString('utf-8') with Node.js StringDecoder:

• headFile: reads forward, the decoder naturally buffers incomplete trailing byte sequences across write() calls. A final decoder.end() flushes any remaining bytes.

• tailFile: reads backwards from file end. The function now collects raw Buffer slices in reverse order, reverses them for correct chronology, then decodes the concatenated buffer as a single UTF-8 stream. Newline counting is done on raw bytes (0x0A is single-byte even in UTF-8), so we stop reading at the right point.

Testing

• server-filesystem test suite: 152 passed (7 test files).

[tarunag10]

I compared this with #4667 and ran the filesystem suite plus two real-file edge cases. This PR passes the existing 46 tests, but both added edge cases fail at fc760fe3:

1. tailFile(file, 2) on discard\\n + 界 + 1017 ASCII bytes + \\nlast returns U+FFFD at the 1024-byte boundary. rawBuffers.push(chunk.slice(...)) stores views into the single reused chunk; later reads overwrite earlier entries. Copying each read (Buffer.from(chunk.subarray(0, bytesRead))) avoids that aliasing.
2. tailFile(file, 0) returns the whole file because newlineCount <= numLines enters the loop and slice(-0) is slice(0).

The same two tests pass on #4667, which also has focused head/tail boundary tests (48/48 filesystem tests versus 46/46 here). I recommend either adopting the copying and zero-line behavior here with regression tests, or closing this in favor of #4667. There is also an unused relevantLines local in the current diff.