Making the Rails Default Job Queue Fiber-Based

A developer patched Solid Queue (Rails 8's default job backend) to support fiber-based execution as an alternative to threads. The motivation came from hitting limits with Async::Job (no job persistence, no Mission Control visibility) while building LLM streaming apps. The patch adds a `fibers: N` config option per worker pool. Key benefits: fiber mode uses only 3 database connections per process regardless of concurrency (vs. threads+2 for thread mode), enabling 200 concurrent jobs across 6 processes with just 18 total DB connections. Benchmarks show 20-27% throughput gains for I/O-bound workloads (LLM streaming, HTTP, sleep) with no regression on CPU-bound work. Thread mode failed stress tests at 50+ concurrent jobs with 2 processes due to exceeding PostgreSQL's default max_connections=100. The implementation uses a FiberPool with an async reactor and semaphore. Mixed worker configs are supported, allowing fiber queues for I/O work and thread queues for CPU-bound jobs. A PR is open on the rails/solid_queue repo.