Restore FastAPI 0.137 support in the Task Execution API

[Revanth14]

Follow-up to PR #68578.

issue #68562

Cadwyn 7.1.0 now declares fastapi>=0.137.1, so the temporary fastapi<0.137.0 cap is no longer needed.

This PR:

• Bumps cadwyn>=7.1.0.
• Relaxes FastAPI to fastapi>=0.137.1.
• Refreshes uv.lock.
• Updates execution API router assembly for FastAPI 0.137's lazy router inclusion behavior.

Bumping to FastAPI 0.137 surfaced a second incompatibility: router dependencies are frozen into each route at include_router() time. The execution API's OpenTelemetry trace-context dependency was previously injected after routers were assembled, so it was silently dropped. The router tree is now assembled through a build-time factory so the dependency is supplied up front, preserving the unsafe-always / only-authenticated / never ordering.

Tests:

• Full execution-API unit suite passes: 480 passed, 4 DB-backend skips

Related: #68578

[Revanth14]

@potiuk heads-up: removing the cap is more involved than just the dependency bump.

FastAPI 0.137's lazy router inclusion changes the router layer behavior: include_router() no longer leaves only materialized child APIRoutes in router.routes; included routers can appear as _IncludedRouter wrappers. So code/tests that iterate router.routes assuming every route has .path, .responses, etc. now break.

I fixed the execution API part in this PR by assembling the trace-context dependency at router-build time, but the bump also exposes core API route-introspection failures, for example:

FAILED core_api/routes/test_routes.py::test_no_auth_routes
AttributeError: '_IncludedRouter' object has no attribute 'path'

So this is effectively a broader FastAPI 0.137 migration that also touches security-relevant route checks. I can push it through in this PR with a small route-materialization helper, or split it into a dedicated migration PR. Do you have a preference? And is the 0.137 migration already tracked anywhere?