Expose HMR retry limit in Vite config vs. keeping it hard‑coded

Goal: Decide whether Vite should expose a configurable HMR retry limit

Vite’s Hot Module Replacement client currently retries a failed update up to a hard‑coded maximum of three attempts before falling back to a full page reload. The constant lives in the client overlay (src/node/server/hmr.ts) and can only be altered by forking Vite or replacing the HMR runtime with a custom plugin, which limits flexibility for teams that want different back‑off strategies or lower latency on flaky networks. An open discussion in the Vite repository weighs adding a server.hmr.retry option against keeping the value internal to avoid configuration overhead and potential misuse.

What trade‑offs exist between exposing this setting and preserving the current default behavior? How would a configurable limit affect duplicate‑write safety and developer experience? Should the API accept a simple number, a back‑off object, or remain unchanged?