feat(runtime): background driver so async work (fetch, timers) resolves on its own

[wytzepiet]

Problem

When JavaScript does async work — a fetch, a setTimeout — that work runs in the background. But it only moves forward when something pokes the runtime. If nothing pokes it, a finished result just sits there undelivered until some unrelated call (like an eval from Dart) happens to come along and poke it.

In a real app those pokes can be far apart. Measured on a physical phone:

	time
fetch to a Convex endpoint, in the app	~15 s
the same request via curl	~100 ms
with a timer poking the runtime every 33 ms	~50 ms

The 15 s lined up exactly with the app's WebSocket ping — the only thing regularly poking the runtime. A 33 ms timer fixed it, which proved the cause — but that timer wakes 30 times a second forever, even when there's nothing to do.

Fix

rquickjs already has the right tool: AsyncRuntime::drive(). It's the background-friendly relative of the existing idle() — instead of running until all the work is done, it keeps running and keeps the background work moving. When there's nothing to do it sleeps instead of spinning, and wakes only when a piece of background work is actually ready. It also shares the runtime fairly, so regular calls like eval still get their turn and nothing gets stuck waiting.

This PR runs that drive() future on a background task, so async work resolves on its own — no polling, no wasteful timer:

• start_drive() — starts the background task. Calling it again while it's already running does nothing. It's async because it has to run inside the async runtime to start the task — a sync version would have no runtime and panic.
• stop_drive() — stops it.
• JsEngine forwards both, and close() stops it on shutdown.

A host that used to poll executePendingJob() on a timer can now just call startDrive() once and let async work resolve as it's ready.

Notes

• Only adds things — no existing method or behavior changes.
• Regenerated the bindings with flutter_rust_bridge_codegen 2.12.0 (matching the runtime, see [Bug report] fjs's codegen version (2.11.1) should be the same as runtime version (2.12.0) #11). The big churn in frb_generated.* is just the auto-generated wiring shifting as new methods are added.
• New test covers start / "a second start does nothing" / stop / still-usable-afterwards. The 74 engine and 32 async tests pass, and the ~15 s → ~100 ms result was confirmed on a physical iPhone.

🤖 Generated with Claude Code

[iota9star]

Review findings:

• Standalone behavior looks good: the new background driver path is covered and cargo test --manifest-path libfjs/Cargo.toml passed locally with 534 tests.

• Integration note with fix: prevent JS stack overflow from crashing the process #15: this PR has a semantic interaction with the stack-safety PR. In a merged feat(runtime): background driver so async work (fetch, timers) resolves on its own #12 + fix: prevent JS stack overflow from crashing the process #15 checkout, start_drive() still runs the background driver with tokio::spawn(self.rt.drive()). That means driver-pumped async JS jobs execute on FRB/Tokio worker threads instead of the dedicated fjs-js executor thread introduced by fix: prevent JS stack overflow from crashing the process #15, so they bypass the larger-stack protection.

  I verified this with a temporary test that checked the thread name from a driver-pumped job; it ran on tokio-rt-worker, not fjs-js.

  Suggested fix after fix: prevent JS stack overflow from crashing the process #15 lands: spawn the background driver through crate::js_executor::spawn(self.rt.drive()) or an equivalent dedicated JS executor path, and add a regression test that proves background-driver jobs run on fjs-js.