test: stabilize server action HMR update (#98322)
### What?
Stabilize the development-mode server action HMR test when an unrelated
Fast Refresh reload occurs while the patched action is being applied.
### Why?
The test retried by dispatching another click before the previous
asynchronous server action had settled. Under CI load, those requests
overlapped with HMR and an unrelated full-page Fast Refresh reload. The
reload reset the client counter, so the correctly updated action
returned exactly `1000`, which the test rejected because it assumed the
pre-reload state was preserved.
### How?
Wait for network idle after each action invocation so retries do not
observe an in-flight response, allow the valid post-reload value of
`1000`, and use a retry window that accommodates CI HMR latency. The
assertion still distinguishes the updated `+1000` action from the
original `+1` implementation without requiring client state to survive
an unrelated reload.
### Verification
- `pnpm test-dev-turbo
test/e2e/app-dir/actions/app-action-node-middleware.test.ts -t "should
support updating the action"` (10 consecutive passes)
- `pnpm test-dev-webpack
test/e2e/app-dir/actions/app-action-node-middleware.test.ts -t "should
support updating the action"` (4 consecutive passes)
- Prettier and ESLint on `test/e2e/app-dir/actions/app-action.test.ts`
<!-- NEXT_JS_LLM -->
<!-- fleet 5793f439-a569-44be-ad19-d456ce9b641c -->
Co-authored-by: vercel-fleet-prod[bot] <318278635+vercel-fleet-prod[bot]@users.noreply.github.com>
Co-authored-by: Tobias Koppers <1365881+sokra@users.noreply.github.com>
