chore(ci): read python pin from pyproject.toml instead of hardcoding per workflow

[rnegron]

Problem

CI workflows hardcode the Python version (~14 pins across 10 workflows), so every patch bump has to touch all of them. This converts them to read the version from pyproject.toml instead. Landing it before the cutover (#59440) means that bump becomes a single requires-python change which every workflow picks up automatically — no per-workflow Python edits in the cutover.

Changes

• 14 hardcoded python-version: pins → python-version-file: pointing at the appropriate pyproject.toml (root, services/llm-gateway/, or tools/hogli/).
• 4 "python-version" strings in the ci-backend.yml jq matrix builder → derived once at job runtime from pyproject.toml via grep + jq --arg pv.
• Net: future Python version bumps touch one line (pyproject.toml) instead of ~14.

How did you test this code?

Agent-authored. YAML syntax check on the modified workflows; grep confirms zero remaining hardcoded python-version pins across .github/workflows/. No runtime test — depends on CI runners exercising the conversion. At this point in the stack pyproject.toml still pins 3.12.12, so the workflows resolve to 3.12.12; the cutover then flips it to 3.13.13 and they follow.

Publish to changelog?

no

🤖 Agent context

Part of the python 3.13 stack: deps (#59439) → uv (#60144) → this → cutover (#59440). Reordered before the cutover (originally sat after it) so the bump stays a clean pyproject.toml flip and this refactor is reviewable on its own.

[rnegron]

Warning

This pull request is not mergeable via GitHub because a downstack PR is open. Once all requirements are satisfied, merge this PR as a stack on Graphite.
Learn more

• chore(python): bump to 3.13.13 #59440
• chore(ci): read python pin from pyproject.toml instead of hardcoding per workflow #59478 👈 (View in Graphite)
• chore(deps): bump uv to 0.11.15 #60144
• chore(deps): bump for 3.13 wheel coverage #59439
• chore(python): prep for 3.13 - asyncio and ast deprecations #59438
• master

This stack of pull requests is managed by Graphite. Learn more about stacking.

[tests-posthog]

Query snapshots: Backend query snapshots updated

Changes: 1 snapshots (1 modified, 0 added, 0 deleted)

What this means:

• Query snapshots have been automatically updated to match current output
• These changes reflect modifications to database queries or schema

Next steps:

• Review the query changes to ensure they're intentional
• If unexpected, investigate what caused the query to change

Review snapshot changes →

[webjunkie]

We might have already tried this, and it was part of rate limit issues.

Since with just giving the file, it must read the file and then figure out what version matches from the specified range and this hit the rate limits.

Might be fixed now or not, I dunno

astral-sh/setup-uv#802
astral-sh/setup-uv#325