[Studio][Bug] Slow broker config preview can overwrite a newer preview with stale values

## Problem

On the Cluster page (Broker 管理 tab), the broker config preview dialog renders whichever `previewClusterConfig` response arrives last, without any request-generation guard. Every comparable request on the same page already guards against stale responses: `nsConfigDiffRequestRef`, `brokerConfigDiffRequestRef`, `connectionTestRequestRef`, plus the registry lists (`web/src/pages/cluster/index.tsx`). `handleConfigPreview` alone does not.

## Evidence

- `handleConfigPreview` awaits `previewClusterConfig(request)` and then unconditionally calls `setConfigPreview(preview)`, `message.success(...)`, and `setConfigPreviewLoading(false)`.
- Reproduction path: open 配置 for a broker, change a value, click 预览 (response A is slow) → close the dialog (Cancel) → reopen 配置 for the same broker, change values again, click 预览 (response B arrives) → slow response A finally resolves → the panel now shows A's diff although the form holds different values.
- A new regression test (`discards a superseded broker config preview response`) fails on the unmodified base: the final assertion `getByText('defaultTopicQueueNums=24')` finds only `defaultTopicQueueNums=16` — the stale first preview overwrote the latest one. The dialog was also re-rendered with `configPreviewLoading` still stuck from the superseded request's `finally` being bypassed by the newer one, and the success toast fires for the stale response.
- Same-file precedent: `keeps the requested broker config diff when a slower response finishes last` (added by the fix for the broker config diff race) exercises the identical pattern with a request ref guard.

## Impact

The preview panel is the safety check users rely on before applying a broker config update across a cluster. Showing a diff computed from values that are no longer in the form (or a stale success toast while the panel is still loading) invites confirming an update whose preview does not match what will be applied.

## Expected behavior

Each preview request carries a generation; only the newest one may write `configPreview`/`configPreviewLoading` or toast. The generation must be invalidated when the dialog opens, when it is closed, and when any form value changes (the existing `onValuesChange` already clears the stale preview panel).

## Related work

- #3292 / its fix PR addressed the same class of race for the broker config diff dialog.
- The connection-test guard and NameServer diff guard already exist in the same file; this gap is only the config preview/submit path.
- No open or closed issue covers the preview request ordering.

## PR

Fix: #4166.

Start in web/src/pages/cluster/index.tsx at handleConfigPreview and compare it with the existing broker config diff, NameServer diff, and connection-test guards. Run the regression test named “discards a superseded broker config preview response”; done means the newest preview remains visible and stale loading state or success feedback does not overwrite it.

Written by the indexing model from the issue text.