Schema reference casing mismatch causes resolver error for paginated components

[nikhil-somani]

Describe the bug
The generated schema references a paginated response component using PascalCase, but the actual schema definition is created in camelCase, leading to a resolver error.

Example error:

Resolver error at paths./public/companies/.get.responses.200.content.application/json; version=v2.13.47.schema.$ref
Could not resolve reference: Could not resolve pointer: /components/schemas/PaginatedPublicCompanyListing does not exist in document

On inspecting the schema output, I noticed that the component is generated, but with a mismatched name (paginatedPublicCompanyListing instead of PaginatedPublicCompanyListing).

To Reproduce
Define a paginated view,
Generate the schema using DRF Spectacular (e.g., via SpectacularAPIView or spectacular --file schema.yml).

Inspect the generated OpenAPI schema and observe that:

The response references #/components/schemas/PaginatedPublicCompanyListing

But the actual schema is defined as paginatedPublicCompanyListing.

Expected behavior
The referenced schema name in the response should match exactly with the generated schema definition.
Specifically, both should consistently use the same casing (either PaginatedPublicCompanyListing or paginatedPublicCompanyListing).

It would also help to have a configuration or naming policy setting to control schema naming convention for paginated components (e.g., PascalCase vs camelCase), avoiding the need for a custom post-processing hook to fix it manually.

Screenshots

Schema sample

      tags:
      - Companies
      security:
      - tokenAuth: []
      responses:
        '200':
          content:
            application/json; version=v2.13.47:
              schema:
                $ref: '#/components/schemas/PaginatedPublicCompanyListing'
            text/csv; version=v2.13.47:
              schema:
                $ref: '#/components/schemas/PaginatedPublicCompanyListing'
          description: Paginated public companies updated

WorkAround I did:-

added a post processing hook to make the ref camelcase instead of pascal case.

Please let me know if this workaround would always be required for a user, even if so, it should show error with helping text.