[BUG] Instance status history is sampled once per instance instead of once per check cycle

### Current Behavior

Instance status history is appended once per instance during each scheduled check instead of once per check cycle.

`InstanceCheckService.doCheck()` iterates every cached instance and calls `collectStateData()` inside the loop:

```java
instanceHealthBeatInfo.values().forEach(instance -> {
... update one instance state ...
collectStateData();
});
```

`collectStateData()` groups all instances by state and appends the counts to `stateHistoryMap` via `updateStateHistory(...)`. With N instances, a single scheduled run appends N history points. The values can also represent intermediate state while the loop is still updating later instances.

### Expected Behavior

The service should update all instance states first, then append one aggregated history sample per scheduled check cycle.

### Impact

The instance data visual API can show compressed/duplicated history and faster-than-real timeline movement when more than one instance is tracked.

### Code Location

- `shenyu-admin/src/main/java/org/apache/shenyu/admin/service/impl/InstanceCheckService.java`
- `doCheck()` calls `collectStateData()` inside the per-instance loop.
- `getInstanceDataVisual()` reads `stateHistoryMap` for the line chart returned by `InstanceController`.

Start by reading shenyu-admin/src/main/java/org/apache/shenyu/admin/service/impl/InstanceCheckService.java, focusing on doCheck(), collectStateData(), and getInstanceDataVisual(). Trace how InstanceController receives the history data. Done means each scheduled check updates all instances before appending exactly one aggregated state-history sample, without changing the visual API’s intended output.

Written by the indexing model from the issue text.