fix: stop leaking a tokio runtime per .cat/.last, consolidate read commands

[cablehead]

Problem

.cat/.last leaked a file descriptor on every call. A long-lived stacks2099 accumulated them until it hit the open-file limit and died:

thread panicked at src/nu/commands/cat_stream_command.rs:136:
Failed to create tokio runtime: Too many open files (os error 24)

Each call spawned a thread that built a fresh tokio::runtime::Runtime and forwarded frames over a std::sync::mpsc. A tokio runtime holds an eventfd and a wakeup socket. With --follow the thread parked on the broadcast receiver waiting for the next append. When the consumer went away the parked thread never noticed, because a std mpsc only reports disconnection on the next send and that send never came. So the runtime and its two descriptors stayed alive for the life of the process. One pair leaked per call.

Fix

store::read is now sync. Its follow task selects on tx.closed() and exits when the receiver drops. Store carries a runtime handle, and .cat/.last stream frames through rx.blocking_recv() on that shared runtime. Nothing builds a runtime per call.

Consolidation

The read commands were four: a ReadMode::Stream pair and a ReadMode::Plain pair. That split is gone. One .cat and one .last serve every caller now.

Historical (non---follow) reads used to collect the whole backlog into a Vec before returning. They stream lazily now, like follow. That meant moving two consumers off the tokio runtime thread, since blocking_recv panics there: the actor config-body eval and the xs eval HTTP endpoint. Both run on a plain std::thread and hand their result back.

Test

test_cat_stream_fd_leak runs .cat --follow in a loop and watches /proc/self/fd. It runs in its own spawned process, because cargo test is parallel and the fd count is process-wide. Before the fix the count grew about 2.8 descriptors per iteration. Now it stays flat.