[FEATURE] Add pagination and infinite scroll to query results

## Is your feature request related to a problem?

LibreDB Studio currently displays only the first 50 rows of a query result using `SELECT TOP 50`.

There is no option to load additional rows. When a table contains more than 50 records, users cannot continue browsing the remaining data without manually changing and executing the query again.

## Describe the solution you'd like

Add paginated query results with infinite scroll support.

LibreDB Studio should initially load 50 rows. When the user approaches the bottom of the results grid, it should automatically request and append the next 50 rows.

The feature should:

* Load results in batches of 50 rows.
* Automatically fetch the next page near the bottom of the grid.
* Append new rows without replacing previously loaded rows.
* Display a loading indicator while fetching the next page.
* Prevent duplicate or concurrent requests.
* Stop requesting data when no more rows are available.
* Display an error and retry action if the next page fails.
* Reset pagination when the query, connection, sorting, or filters change.
* Support the pagination syntax required by each database provider.

## Describe alternatives you've considered

* Manually change `TOP 50` to a larger value. This may cause slow queries, large responses, and high browser memory usage.
* Add a **Load More** button. This would solve the limitation but would require repeated manual interaction.
* Use numbered pagination. This provides explicit page navigation but is less convenient for continuously exploring records.
* Load all rows at once. This could significantly affect database and browser performance.

## Use Case

A user opens or queries a table containing thousands of rows. LibreDB Studio initially displays the first 50 records.

As the user scrolls toward the bottom of the results grid, the next 50 records are loaded and appended automatically. The user can continue browsing without modifying or re-executing the query.

## Additional Context

Currently, the generated query is limited to `SELECT TOP 50`, and the interface does not provide a way to retrieve subsequent results.

The implementation will likely require changes to both the query execution layer and the results grid.

## Implementation Notes (Optional)

* Introduce pagination metadata such as:

* `limit`
* `offset` or cursor
* `hasMore`
* Use the correct pagination strategy for each database:

* SQL Server: `ORDER BY ... OFFSET ... ROWS FETCH NEXT ... ROWS ONLY`
* PostgreSQL/MySQL/SQLite: `LIMIT ... OFFSET ...`
* Oracle: `OFFSET ... ROWS FETCH NEXT ... ROWS ONLY`
* Cursor-based pagination where offset pagination is unavailable.
* Use an `IntersectionObserver` sentinel or the grid component's visible-range callback.
* Trigger the next request only when `hasMore && !isLoadingMore`.
* Use stable ordering to prevent missing or duplicated rows between pages.
* Consider row virtualization to prevent performance degradation after many pages are appended.
* Add tests for pagination, automatic loading, duplicate-request prevention, errors, query resets, and end-of-results behavior.

## Related Issues

No related issues identified.