Use shared pagination option models instead of redeclaring pagination parameters in TypeSpec

[joseharriaga]

We created shared models for pagination parameters, but many pagination operations still redeclare those query parameters inline instead of reusing the shared models.

For example, listVectorStores defines limit, order, after, and before directly even though VectorStoreCollectionOptions already represents the same inputs. This creates duplication and makes it easy for the shared models to drift from the REST API shape.

There is also a naming issue in some shared models. Parameters like pageSizeLimit, afterId, and beforeId should use the REST names limit, after, and before. Any .NET-specific renames should happen in client.tsp, not in the base REST-facing TypeSpec.

Requested change

1. Update pagination operations to spread the appropriate shared collection options model instead of redeclaring pagination parameters inline.
2. Rename shared pagination fields to match the REST API contract.
3. Keep any client-specific renames in client.tsp only.
4. Apply this consistently across all pagination operations, not just vector stores.

Acceptance criteria

1. Pagination operations no longer duplicate shared pagination parameter definitions.
2. Shared pagination models use the correct REST parameter names.
3. Client renames are handled only in the client customization layer.
4. Codegen is regenerated after the TypeSpec changes.