Simplify the worker and reorganize the execution pools

[rosa]

Hey @crmne! While finishing the review of rails#728 (thanks so much for all the work on it and for your patience! 🙏), I ended up with some changes that go beyond style tweaks, so rather than force-pushing them over your branch directly, here's a PR against it so you can see and weigh in on them:

• Make worker metadata static again (two commits: first limiting refreshes to heartbeats, then removing the gauge altogether): keeping the inflight gauge fresh required a mutex + dirty-flag in the worker, an extra UPDATE per claiming poll (up to 10/s per worker at the default polling interval), and had the poller and heartbeat threads racing to update the same row. And once refreshed only on heartbeats, the gauge could be stale by up to a heartbeat interval — better not to show it than to show stale info, especially since the exact count is always available from claimed executions. Workers now register pool_type and pool_size once, both constant. With the dirty-tracking gone, the pool callback's only job is waking the worker when capacity frees up, so it gets its old on_idle name back.
• Start the fiber pool's reactor lazily, on first use: this makes the pool fork-safe by construction — safe to build at any point relative to forking, rather than relying on careful call ordering in the worker — and matches the thread pool, which already builds its executor lazily. The async gem is also required lazily there, so setups without fiber workers never load it. There's a new unit test covering the build-then-fork case, plus an integration test exercising the full supervised fork + fiber worker lifecycle.
• Simplify worker initialization: with both pools lazy, the worker can build its pool directly in initialize again — no boot override or deferred pool options needed — merge defaults unconditionally, and pick the pool type with a single check. Instantiated directly with no pool options, a worker defaults to threads; with both, fibers win (the configuration forbids that combination anyway).
• Consolidate validation in Configuration: the worker no longer duplicates the threads + fibers rejection, and the async-dependency and isolation-level checks moved from the fiber pool into Configuration itself, where they're surfaced through valid? and check on every supervised path, before any process is instantiated. Internal classes trust their callers, same as the scheduler does with recurring tasks.
• Extract SolidQueue::Pool as the pools' base class: both pools shared the capacity ledger (reserve/restore accounting, idle notification, and the reserve-then-schedule shape of post), so that now lives in an abstract Pool that also builds the right pool for a worker via Pool.build, mirroring how Supervisor relates to ForkSupervisor and AsyncSupervisor. Each pool is left with just its scheduling mechanism, and the pool type is derived from the class name. (The old SolidQueue::Pool back-compat alias is removed early in the branch; the name returns here as the actual abstraction — it was internal API with no remaining references.)
• Report errors escaping the execution future: the thread pool's inline rescue covers job execution, but an error raised while restoring capacity or waking the worker would reject the future with nobody watching — this restores the on_rejection backstop the old pool had. Relatedly, posting now scopes its rescue to the code that runs after capacity is reserved, instead of tracking reservation with a local flag.

Each commit is independently green, so the history bisects cleanly. Merging this into your branch will update the main PR. If you'd rather discuss any of these, happy to!

🤖 Generated with Claude Code

[crmne]

Thanks so much for this, Rosa! I have merged the PR.

I went through the changes carefully and really appreciate the attention to detail here. In particular:

• Keeping worker metadata static makes sense. ClaimedExecution remains the authoritative source for live in-flight work and is what Mission Control Jobs queries, so removing the duplicated gauge avoids extra writes and synchronization without losing accurate visibility.
• Consolidating the checks in Configuration keeps the database-pool sizing behavior intact while surfacing dependency and isolation errors before processes are instantiated.
• Starting the reactor lazily makes the fiber pool fork-safe by construction and keeps Async unloaded for thread-only configurations.
• The shared pool abstraction and simplified worker initialization remove a substantial amount of bookkeeping.

I also traced the lazy-start lifecycle and confirmed that the worker is the sole producer posting into its pool, so the simpler initialization remains appropriate.

I ran the focused tests, the full SQLite suite, and RuboCop successfully. Thanks again. This leaves the implementation considerably cleaner and easier to reason about.

[rosa]

Awesome! Huge thanks for reviewing this, @crmne! Really appreciate it.

From my side, this should make the main PR ready to be merged now. Do you think you need to test this again, in the same way you tested the original PR? If so, happy to wait for that.

[crmne]

Yes, I think rerunning the benchmark suite is worthwhile. I am away from home and the original runs were done on my desktop, so I cannot produce an exact comparison with those numbers until next week.

I can run the complete suite on my laptop in the meantime. Since thread and fiber modes will be benchmarked together on the same machine, the results will still be internally comparable. I just would not compare the absolute numbers directly with the previous desktop results.

My preference is to do that now so the merge is not blocked, then repeat it on the desktop next week only if we want an exact comparison with the published results.