Cap wasm worker pool growth

[raqeebshafeeque]

Summary

Cap wasm WorkerPool growth and add an explicit lazy hard-cap constructor for web worker lanes.

Problem

WorkerPool::new(Some(1), ...) prewarmed one worker, but did not enforce a maximum of one live worker. Under bursty FRB traffic, the pool could spawn additional workers and retain them.

For embedders using FRB thread lanes as logical single-worker lanes, this meant a “single worker” lane could accidentally become a growing worker pool, increasing browser worker count and memory usage.

Changes

• Add WorkerPool::new_with_max(initial, max_workers, ...).
• Add WorkerPool::new_raw_with_max(...).
• Track live workers separately from idle workers.
• Queue work FIFO once max_workers is reached.
• Reuse workers after completion.
• Revoke generated blob worker URLs after worker creation.
• Preserve existing WorkerPool::new(...) API while making its worker count act as a hard cap.
• On wasm, run Thread::Main normal/async calls inline instead of dispatching them through a worker pool.

Why

This allows embedders to create lanes like:

WorkerPool::new_with_max(0, 1, ...)

Meaning:

• lazy spawn / no startup prewarm
• hard maximum of one worker
• FIFO queue under contention

This is useful for strict single-threaded wasm lanes such as CRDT/Loro document access.

Validation

• cargo fmt -p flutter_rust_bridge
• cargo check -p flutter_rust_bridge --target wasm32-unknown-unknown --features serde_json,uuid -q