Run executor submissions inline instead of fencing them

[dhruvl]

run_in_executor no longer fences. The submitted function runs synchronously at an ordinary scheduled step — ordered by the seeded draw, labelled executor:<function> in the trace, costing no virtual time — and its result or exception lands on the returned future the way an executor worker would land it. asyncio.to_thread reaches the loop through this call, so it now works under simulation.

What stays honest about it:

• The executor argument is never used. There is no pool and nothing runs concurrently, and a test proves the object is never touched. set_default_executor still fences: a pool that would never run anything is refused rather than accepted.
• call_soon_threadsafe from the loop's own thread is now call_soon, which is all it ever was without a second thread. From any other thread it still fences — a real thread's timing is outside the simulation — and a test drives that from an actual second thread.
• anyio.to_thread is not thereby supported, and the docs say why precisely: its worker threads are real ones spawned through no loop API, so no fence can catch the escape at the source, and a real thread racing a virtual clock ends in the cross-thread fence, a hang, or the caller's own timeout. (Measured, not guessed — the timeout-first race was observed while writing the docs.)

design.md keeps its argument against passthrough to a real pool and marks this as the one place the line moved without crossing it. The probe-harness tests lean on add_reader as their canonical fence now that their old one stopped fencing.

Determinism is untouched where it is promised: the submission is a ready-queue entry like any other, a cancelled future means the function never runs, and a trace-hash test pins two runs of the same seed to the same hash.