Instance inventory lacks vendor filtering and server-side pagination

## Problem

The instance inventory is always returned in full and cannot be narrowed by vendor. In multi-cloud deployments that manage Apache, Aliyun, and Tencent instances together, operators cannot filter the inventory to one vendor, and large inventories are rendered in a single unbounded table.

## Current behavior and reproduction

1. Open **Instance** management on a multi-cloud installation with many instances.
2. Try to list only Aliyun instances: there is no vendor filter — only type and search.
3. The table renders every instance at once (`pagination={false}`), which degrades as the inventory grows.

`GET /api/instances` accepts only `type` and `search`:

```java
@GetMapping
public Result> listInstances(
@RequestParam(required = false) InstanceType type,
@RequestParam(required = false) String search) {
return Result.ok(instanceService.listInstances(type, search));
}
```

Although the data model and page already distinguish vendors (`APACHE`, `ALIYUN`, `TENCENT` via `InstanceVendor`), there is no vendor query parameter and no paged instance endpoint.

## Proposed behavior

- Add `GET /api/instances/page` returning a `{ items, total, page, size }` contract.
- Accept the existing `type` and `search` filters plus a new `vendor` filter.
- Normalize the vendor value case-insensitively and reject unknown values with a clear error.
- Validate that `page >= 1` and `pageSize` is within 1–100.
- Reuse the existing instance list pipeline — resource-count enrichment, region-name resolution, and stable vendor/region/name ordering — so paged rows have the same shape and quality as the current list.
- Add a vendor selector to the instance page and replace the unbounded table with server-side pagination.
- Reset to the first page when type, vendor, or search changes.
- Keep the existing non-paged endpoint for callers that need the full list (for example export and selectors).

## Acceptance criteria

- [ ] `GET /api/instances/page` returns the paged contract with a result-set-wide total.
- [ ] `vendor` is normalized case-insensitively; unknown values return 400.
- [ ] `page`/`pageSize` bounds are validated (page ≥ 1, 1 ≤ pageSize ≤ 100).
- [ ] Paged rows retain resource-count enrichment, region names, and stable ordering.
- [ ] The page offers a vendor selector and server-side pagination, resetting to page 1 on filter changes.
- [ ] The existing non-paged endpoint is unchanged for full-list callers.
- [ ] Backend tests cover validation, normalization, pagination math, and filter forwarding; page tests cover the new contract.

## Importance

Should-have. Multi-cloud operators need vendor scoping to answer "which Aliyun instances do we manage?", and unbounded rendering becomes unusable as the inventory grows. Current workaround: export or manually eyeball the full list.

## Duplicate check

Searched open and closed issues/PRs for `instance vendor filter`, `instance pagination`, `instance inventory filter`, `instance page endpoint`. No existing issue or PR adds vendor filtering or server-side pagination to the instance inventory.

Start at the existing GET /api/instances endpoint and the instance management page, then trace the current list pipeline and table rendering. Verify how resource-count enrichment, region-name resolution, ordering, and existing backend/page tests are covered. Done means a validated /api/instances/page contract, vendor filtering, server-side pagination with filter resets, preserved full-list callers, and tests for the listed acceptance criteria.

Written by the indexing model from the issue text.