Fix missing HTTP access logs when api-server omits the core app

[manish1337]

An api-server started without the core app — for example --apps execution, the shape used to run
the Task Execution API as its own deployment — serves requests normally but emits no access log
lines at all.

Three separate places disable the built-in access loggers, all resting on the premise that
HttpAccessLogMiddleware handles access logging:

• AirflowUvicornWorker.CONFIG_KWARGS — access_log: False
• the uvicorn kwargs built in api_server_command
• uvicorn.access / gunicorn.access muted (handlers: [], propagate: False) in logging_config

That premise only held while the middleware was installed inside the "core" in apps_list branch of
create_app, so an --apps selection without core had no access-log producer at all — and because
the loggers are muted at the logging-config level too, no configuration could bring the records back.

This installs the middleware for every apps selection, which makes the premise true again rather
than adding a fourth conditional. The alternative — enabling uvicorn's own access log when core is
absent — needs three coordinated conditionals across three files and would give execution-only
deployments a different log format from every other deployment.

For anyone running the Task Execution API as its own deployment, this restores per-request telemetry
(latency, status codes, endpoint counts) for the component every running task depends on for
heartbeats, state transitions and XComs.

Verification

Started a real api-server and issued a marked request, before and after the change:

--apps	uvicorn	gunicorn
execution	no record → logged	no record → logged
core	logged	logged
all	logged	logged

• Middleware order for core/all is unchanged: [HttpAccessLogMiddleware, GZipMiddleware, JWTRefreshMiddleware].
• The generated OpenAPI specs are byte-identical with and without the change.
• The added test fails on [execution] without the fix and passes with it.
• airflow-core/tests/unit/api_fastapi (3750), providers/fab (536) and providers/common/compat
  (197) pass. The test_hitl.py and example-Dag failures seen locally also fail on unmodified
  main, so they are unrelated.

Note for reviewers: #64523 (open) also edits init_middlewares to add a metrics middleware, so the
two may conflict textually.

---

Was generative AI tooling used to co-author this PR?

• Yes — Claude Code (Opus 5)

Generated-by: Claude Code (Opus 5) following the guidelines

[ColtenOuO]

LGTM overall.

Just a small suggestion: If you want to update your branch with the latest main, consider using rebase instead of merge.

This helps keep the commit history cleaner and easier to follow.