Should `quart.make_response` be typed as returning `Response`?

Steps to reproduce

With the following Quart app:

from quart import Response, make_response
from quart_trio import QuartTrio

app = QuartTrio(__name__)


@app.route("/")
async def hello_world() -> Response:
    return await make_response("<p>Hello, World!</p>")


if __name__ == "__main__":
    app.run()

mypy fails because make_response does not return a Response:

quart_app.py:9: error: Incompatible return value type (got "quart.wrappers.response.Response | werkzeug.wrappers.response.Response", expected "quart.wrappers.response.Response")  [return-value]

Expected result

I would expect validation to pass. Indeed, the equivalent Flask app passes validation:

from flask import Flask, Response, make_response

app = Flask(__name__)


@app.route("/")
def hello_world() -> Response:
    return make_response("<p>Hello, World!</p>")

Workarounds

1. Use return "<p>Hello, World!</p>" and mark the return type as str. But figuring out the right type is tiring, is a maintenance burden and arguably introduces unnecessary variation in the code.
2. Use return quart.Response("<p>Hello, World!</p>") but it quickly breaks for more complex types. I spent a lot of time trying to understand why quart.Response({"headers": "foo", "params': "bar"}) was returning "headersparams"!
3. Type the return as quart.typing. ResponseTypes. This is what I'm doing right now in the urllib3 tests (https://github.com/urllib3/urllib3/pull/3193) but I would rather use Response.

Environment

• Python version: 3.12.0
• Quart version: 0.19.3 (quart-trio 0.11.0)

Start at the quart.make_response entry point and inspect its return typing against the reported mypy error and Flask's behavior. Done means the provided Quart example type-checks with a Response return annotation without requiring ResponseTypes; verify the change with the repository's relevant typing tests if available.