feat(fuse): async read-ahead buffer for smoother FUSE throughput

[javi11]

Summary

• Add AsyncReadBuffer at the FUSE layer that wraps ReadAtContext with a background goroutine filling a ring buffer
• FUSE reads now pull from pre-filled memory instead of blocking on NNTP segment downloads
• Configurable via async_buffer_size in FUSE config (default 8MB, 0 to disable)
• Frontend UI added for the new setting in the Streaming Engine section

Problem

FUSE reads blocked synchronously on NNTP segment downloads. Profiling showed 66.7% of transfer time was stalling with 193 gaps >100ms during a 2.3GB file transfer. During active reads throughput was 111 MB/s, but the pipeline stalled whenever reads caught up to the download frontier.

Solution

Inspired by rclone's AsyncReader (which provides smooth reads even without VFS cache), this adds an AsyncReadBuffer that:

1. Spawns a background goroutine that continuously reads from the source into a ring buffer
2. FUSE reads serve from pre-filled memory (microseconds) instead of blocking on network (milliseconds)
3. Only activates for files larger than the buffer size (skips Finder/Spotlight metadata reads)
4. Uses lazy initialization — no memory allocated until first read
5. Lives at the FUSE level only — WebDAV path is unaffected

Results

Metric	Before	After
FUSE cat speed	~24 MB/s (94s)	~41 MB/s (55s)
rclone cat speed	~43 MB/s (53s)	unchanged
Gap vs rclone	75% slower	~4% slower

Test plan

• 8 unit tests with -race for AsyncReadBuffer (sequential reads, slow source, error propagation, concurrent read+close, passthrough, GetBufferedOffset)
• go build ./... passes
• Existing handle tests updated and passing
• Manual: rebuild, restart, dd if=<fuse-file> of=/dev/null bs=1m — verify ~40+ MB/s
• Manual: check pprof heap — verify ~8MB per active file stream
• Manual: verify Finder browsing doesn't trigger buffer allocation for small files