[Studio][Bug] Registry Broker configuration actions can target the wrong instance

## Severity

High (P1). This is a silent control-plane write to a different RocketMQ instance than the Broker row selected by the operator.

## Problem

The Cluster page displays Broker rows from the global NameServer registry through `listRegistryClusters()`. Broker configuration preview/update and config-diff actions still attach the instance selected by the page route.

After registry-based discovery was introduced, the current route instance and the source instance of a registry row are no longer necessarily the same. If two instances use a common cluster name such as `DefaultCluster`, selecting a row discovered from instance B while the route points to instance A sends `{ id: "DefaultCluster", instanceId: "instance-a" }`. The backend correctly honors that payload and can update A even though the operator clicked B.

## Reproduction

1. Configure two Apache instances:
- `instance-a` -> `ns-a:9876`
- `instance-b` -> `ns-b:9876`
2. Let both NameServers report a cluster named `DefaultCluster`, with different Broker addresses.
3. Register `ns-b:9876` in the NameServer registry.
4. Open `/cluster?instanceId=instance-a`.
5. In the global Broker table, open configuration for a Broker discovered from `ns-b:9876` and submit a change.

### Actual behavior

The update request contains:

```json
{
"id": "DefaultCluster",
"instanceId": "instance-a"
}
```

The backend resolves and updates instance A.

### Expected behavior

Every registry row action must be routed through the unique Apache instance whose endpoint owns that row. If ownership cannot be established unambiguously, configuration actions must fail closed.

## Impact

The operation can silently change the wrong production cluster's flush mode, auto-create settings, queue counts, maximum message size, retention, or permissions. A successful response does not reveal that the target was wrong.

## Root cause

- `web/src/pages/cluster/index.tsx` loads all registry clusters without instance scope.
- Broker rows retain their registry cluster but no source instance identity.
- `buildConfigUpdateRequest` and Broker config diff previously read `selectedInstanceIdRef.current`, which represents the route, not the row.

## Regression boundary / duplicate check

- #1243 / #1244 added the selected-instance API contract, but #1243 explicitly left broader cluster discovery/action routing out of scope.
- #2342 later moved the Broker table to global registry discovery without assigning an instance identity to each row.
- #2595 concerns repeated config reads for duplicate Broker addresses, not writes to the wrong instance.
- Searches for `listRegistryClusters updateClusterConfig` and equivalent registry/selected-instance terms found no issue or PR covering this failure.

## Suggested acceptance criteria

- Canonicalize the full NameServer address set and map a registry endpoint to exactly one Apache instance.
- Use the row's instance for Broker configuration preview, update, and config diff.
- Freeze the target when a modal opens so a later route change cannot retarget the write.
- Discard preview/diff responses from a closed, superseded, or edited modal generation.
- Refresh the global registry snapshot after successful and partially successful updates.
- Disable configuration actions for missing or ambiguous mappings.
- Preserve global registry visibility.
- Cover cross-instance, route-change, address-order/separator, and ambiguous-mapping cases in tests.

Start in web/src/pages/cluster/index.tsx, tracing listRegistryClusters, Broker row data, buildConfigUpdateRequest, and the Broker config diff path that currently uses selectedInstanceIdRef.current. Ensure actions use an unambiguous row-owned instance and remain fixed across modal and route changes. Add coverage for cross-instance routing, address-order and separator variations, route changes, ambiguous mappings, and stale modal responses.

Written by the indexing model from the issue text.