ci: run python provider tests in pr-checks

[devNull-bootloader]

This pull request updates the CI workflow in .github/workflows/pr-checks.yml to add support for running Python unit tests alongside the existing JavaScript tests. The most important changes are grouped below:

Python environment setup and testing:

• Added a step to set up Python 3.12 with pip caching using actions/setup-python@v5.
• Added steps to install Python test dependencies (pytest, pytest-asyncio, httpx) and run Python unit tests in the python/tests directory.

[Copilot]

Pull request overview

This PR extends the existing PR Checks GitHub Actions workflow to also run the repository’s Python unit tests (in addition to the current Bun/JavaScript checks).

Changes:

• Adds a Python 3.12 setup step to the pr-checks workflow.
• Installs Python test dependencies (pytest, pytest-asyncio, httpx) in CI.
• Runs pytest against python/tests.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

Pull request overview

Copilot reviewed 2 out of 2 changed files in this pull request and generated 3 comments.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Vasanthdev2004]

Rechecked the current head 54ced5cc98b86fb772bd6df9bf68510c79238cda against current origin/main.

I don't have any code-runtime regressions from the new Python test step itself ? the Python tests pass locally, and build/smoke still pass. I still can't approve because the workflow change introduces a CI security regression and a smaller maintenance risk.

1. .github/workflows/pr-checks.yml:33
   This adds actions/setup-python@v5 as a floating tag, while the rest of the workflow pins third-party actions to full SHAs (checkout, setup-node, setup-bun).

   That weakens the current supply-chain hardening and makes future runs non-reproducible if v5 is updated or retagged. In this repository, that is a regression in the workflow?s security posture, so I would block on pinning it the same way as the other actions.

2. Non-blocking: .github/workflows/pr-checks.yml:37,48-51 and python/requirements.txt:1-3
   The PR adds python/requirements.txt, but CI still installs a separate hardcoded package list instead of installing from that file. That creates two sources of truth, so future dependency changes can drift unless both places are updated together.

What I verified on this head:

• py -3 -m pip install --upgrade pip
• py -3 -m pip install pytest pytest-asyncio httpx
• py -3 -m pytest -q python/tests -> 44 pass
• bun run build -> success
• bun run smoke -> success

I would be comfortable after:

• pinning actions/setup-python to a full commit SHA
• optionally switching the install step to py -3 -m pip install -r python/requirements.txt so the cache key file is also the actual dependency source

[Copilot]

Pull request overview

Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[devNull-bootloader]

@Vasanthdev2004 Thanks for the feedback; should be fixed now!

[Copilot]

Pull request overview

Copilot reviewed 2 out of 2 changed files in this pull request and generated no new comments.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Vasanthdev2004]

Rechecked the latest head 5ebae97b57f7d25e331458467d0cc71f307850e1 against current origin/main.

The earlier maintenance note is fixed on this revision: the workflow now installs from python/requirements.txt, so there is no longer a duplicate dependency source.

The remaining blocker is still .github/workflows/pr-checks.yml:33: actions/setup-python@v5.0.0 is a floating tag while the rest of this workflow pins third-party actions to full commit SHAs. For a workflow that runs on every PR, that weakens the current supply-chain hardening because future runs can execute different code than what was reviewed here if the tag is moved or retargeted.

What I rechecked on this head:

• py -3 -m pip install -r python/requirements.txt
• py -3 -m pytest -q python/tests -> 44 passed
• bun install --frozen-lockfile
• bun run build -> success
• bun run smoke -> success

I would be comfortable after pinning actions/setup-python to a full commit SHA, consistent with checkout, setup-node, and setup-bun.

[devNull-bootloader]

@Vasanthdev2004 done!

[Copilot]

Pull request overview

Copilot reviewed 2 out of 2 changed files in this pull request and generated no new comments.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Vasanthdev2004]

Rechecked the latest head 339d757478427210ffb2feb5e13f3bdfb8bb36c9 against current origin/main.

The remaining blocker from my previous review is fixed on this head: .github/workflows/pr-checks.yml now pins actions/setup-python to a full commit SHA, consistent with the rest of the workflow.

The final diff from the last reviewed head is just that one-line pin change:

-        uses: actions/setup-python@v5.0.0
+        uses: actions/setup-python@0a5c61591373683505ea898e09a3ea4f39ef2b9c # v5.0.0

What I rechecked on this head:

• full workflow contents in .github/workflows/pr-checks.yml
• py -3 -m pip install -r python/requirements.txt
• py -3 -m pytest -q python/tests -> 44 passed

I also attempted to rerun bun install --frozen-lockfile, bun run build, and bun run smoke in this fresh Windows worktree, but Bun hit local dependency-resolution failures after install that were not related to the one-line workflow pin change. Since the only code delta from the previously reviewed head is the SHA pin above, I am not treating those local Bun resolution issues as PR-specific blockers for this final revision.

[devNull-bootloader]

@Vasanthdev2004 Thank you!