[Studio][Bug] Dashboard Metrics Explorer keeps the previous instance's custom query result after an instance switch

[Studio][Bug] Dashboard Metrics Explorer keeps the previous instance's custom query result after an instance switch

## Problem

The home dashboard mounts one `MetricsExplorer` and only swaps the `instanceId` prop when the instance selector changes (web/src/pages/home/dashboard.tsx:408). On that switch the profile panels re-run through `loadAll`, but nothing re-runs or clears the **custom query panel**: it keeps rendering the previous instance's PromQL result (or error) while the instance selector already shows the new instance.

## Evidence

- `web/src/components/MetricsExplorer.tsx` at 6c24d2ed: the reload effect (lines 648-671, keyed on `loadAll` which changes with `instanceId`) re-runs only `loadAll(initialProfile, ...)`; `runCustomQuery` is invoked solely from `activateDataSource`, the data-source-scope fallback effect (lines 822-845), the refresh button and direct user actions - none of which fire for an instance change with the default source. The cleanup at lines 668-671 only invalidates in-flight requests; `customPanel` state survives.
- The scope fallback effect proves the intended pattern: when the selected data source leaves the instance scope, both `loadAll` and `runCustomQuery(appliedCustomPromql)` are re-run. The instance switch with a still-valid (e.g. default) source has no equivalent.
- A regression test in the linked PR reproduces it: run a custom query against `instance-11`, rerender with `instance-22`; the custom expression is never queried again (`queryMetrics` calls for it stay at 1). After the fix it is queried a second time.

## Impact

In a monitoring dashboard, showing instance A's chart while the selector says instance B is misleading: the user can read wrong values as current. Recovery requires manually pressing refresh after every instance switch.

## Expected behavior

On an instance change, the committed custom query re-runs against the new instance (same behavior the data-source-scope fallback already implements). When the selected data source drops out of the new instance's scope, the existing fallback effect re-runs both flows, so that path needs no duplicate request.

## Related work

- #3304 / merged fix (#3299) made the profile panels and the custom query independent request guards in this component; #4188 / #4189 fixes the range reset on the same instance-switch path. Both leave the custom panel's re-run gap untouched.

## PR

Fix: #4265.

Read web/src/components/MetricsExplorer.tsx alongside the home dashboard mount at web/src/pages/home/dashboard.tsx:408; compare the reload effect with the data-source-scope fallback effect. Run the regression test described in the issue, and consider the work done when a committed custom query is queried again for the new instance without duplicating the fallback request.

Written by the indexing model from the issue text.