Model import shadows HTTP `Client` import when a schema is named `Client`

Describe the bug

When an OpenAPI spec contains a schema named Client, the generated endpoint modules import both the HTTP Client class and the Client model class under the same name. The model import silently shadows the HTTP client import, making Client in type annotations refer to the wrong class.
endpoint_module.py.jinja unconditionally emits:

from ...client import AuthenticatedClient, Client

Then endpoint.relative_imports adds model imports. When a model is also named Client, the result is:

from ...client import AuthenticatedClient, Client   # HTTP client
from ...models.client import Client                  # model — shadows the line above

This causes Client in _parse_response and _build_response type annotations to resolve to the model instead of the HTTP client class.

OpenAPI Spec File

Minimal reproduction:

openapi: "3.0.3"
info:
  title: Minimal repro
  version: "1.0"
paths:
  /api/clients/{id}:
    patch:
      operationId: update_client
      tags:
        - client
      parameters:
        - name: id
          in: path
          required: true
          schema:
            type: string
      requestBody:
        content:
          application/json:
            schema:
              type: object
              properties:
                name:
                  type: string
      responses:
        "200":
          description: OK
          content:
            application/json:
              schema:
                $ref: "#/components/schemas/Client"
components:
  schemas:
    Client:
      type: object
      properties:
        name:
          type: string

In the generated api/client/update_client.py, line 6 imports Client from ...client and line 10 re-imports Client from ...models.client, shadowing it.

Desktop (please complete the following information):

• OS: macOS 15 (ARM64)
• Python Version: 3.13
• openapi-python-client version: 0.27.1 (also verified on 0.28.3)

Additional context

We worked around this by using custom templates.

Inizia da endpoint_module.py.jinja e dalla logica alla base di endpoint.relative_imports, quindi genera la specifica OpenAPI minima a partire dall’issue. Controlla gli import nella api/client/update_client.py generata e le annotazioni di _parse_response e _build_response. Il lavoro è completato quando uno schema denominato Client non fa più sì che il riferimento a HTTP Client venga oscurato.