refactor(qwp): drive direct-pool SF recovery from one long-lived background thread

Direct SF pools no longer run inline, construction-time recovery, and no
longer revive a per-attempt recovery driver. Each direct pool now owns a
single long-lived background recovery thread: it scans retired/stranded
slots off the construction path, parks indefinitely when the scan is
complete, and re-parks with a bounded wait between failed attempts. It
exits only on close or interrupt.

Release callbacks no longer create or revive threads. They re-arm the scan
cursor under the pool lock and then LockSupport.unpark the single driver;
the retained-permit ordering closes the callback-before-park lost-wakeup
window. This removes the double-driver race and retires the transactional
revival token (recoveryDriverRunning, releaseRecoveryDriverOwnership,
reviveDirectRecoveryDriverIfNeeded, revivedStartupRecoveryThread,
startupRecoverySignal) in favor of one scan with one owner.

Construction no longer blocks on replay. The clean-release re-arm fix is
preserved: reclaimSlot() calls rearmRecoveryScanIfStranded() so a clean
flock release that frees a dir still holding stranded data re-arms and
unparks the scan. Deferred pools own no private thread and remain
PoolHousekeeper-driven; unpark(null) there is a harmless no-op. Shutdown
unparks and joins only the single driver and never blocks on delivery;
durable leftovers wait for restart. Java 8 stays green via
Compat.onSpinWait, and the test-only manual drive helpers now refuse
direct pools to keep the one-owner invariant.

Author: bluestreak01