Follow-ups from SERVER-131575 (AsyncWorkScheduler use-after-free fix)

1. Remove unsafeToInlineFuture() from the targeting chain. scheduleRemoteCommand targets via findHost().thenRunOn(_executor).unsafeToInlineFuture().then(...). It works because thenRunOn(_executor) re-anchors delivery, but unsafeToInlineFuture() is a sharp tool and the continuation's thread isn't guaranteed. Rework the targeting/send chain to stay an ExecutorFuture end-to-end.
2. Anchor the executor through the continuation chain. Capture getExecutor() down the scheduleRemoteCommand continuations so the executor object is guaranteed to outlive them (per samanca's review suggestion).
3. Re-evaluate/document holding _mutex across _executor->schedule() calls.* Vetted safe for ThreadPoolTaskExecutor (it refuses with ShutdownInProgress rather than running the callback inline), but it's fragile if the executor implementation changes; either stop holding the lock across the schedule call or document the invariant.
4. (Optional) Note the GuaranteedExecutor::enforceRunOnce invariant-on-pool-reject race for completeness.

Consider backporting alongside SERVER-131575 where the same code exists.