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