vim.uv event loop: bounding RPC latency when concurrent clients queue behind plugin callbacks

Neovim services RPC requests from external clients on its single-threaded libuv event loop, so concurrent requests are effectively serialized. Documented behavior is that long-running Lua work in a callback — a timer-driven buffer scan, for instance — delays everything else pending on the main loop, including queued RPC responses.

The goal here is a configuration decision for a plugin that performs periodic Lua-heavy work while remote clients issue requests concurrently. Assume Neovim 0.10 or later, where vim.uv is the preferred alias for the libuv bindings and vim.loop remains available; confirm the alias and deprecation status for the pinned release before relying on either name.

• Buffer state must remain consistent, so core editor mutations cannot be parallelized across threads.
• The periodic work is CPU-bound rather than I/O-bound, so offloading via uv.spawn-style child processes does not map directly onto it.

Specific questions:

1. What is the recommended way to slice long Lua computations so that queued RPC requests are serviced within a predictable interval?
2. Do vim.schedule deferrals or vim.uv timer callbacks provide any fairness or ordering guarantee relative to queued RPC requests?
3. Which measurable signal best distinguishes event-loop starvation from genuinely slow request handling on the client side?