ci(tests): read vars.CI_RUNS_ON, with ubuntu-latest as the fallback

[ywatanabe1989]

The problem

The repository variable CI_RUNS_ON was set on this repo to point CI at our own
hardware. It changed nothing, because the tests workflow never READ it — the job
hardcoded runs-on: ubuntu-latest. The variable write was verified; the effect was
not. A rerun still landed on a GitHub-hosted runner ("GitHub Actions 1000048594",
16m57s).

What now consults it

.github/workflows/pytest-matrix-on-ubuntu-py3-11-3-12-3-13.yml, job test:

runs-on: ${{ fromJSON(vars.CI_RUNS_ON || '["ubuntu-latest"]') }}

Same pattern already proven in scitex-agent-container, whose jobs demonstrably
run on scitex-0X-org-cpu-01.

• Where CI_RUNS_ON is SET (currently ["self-hosted","Linux","X64","scitex-org-cpu"]),
  the matrix runs on our compute pool.
• Where it is UNSET (a fork, a clone, any repo that never got the variable), the
  literal '["ubuntu-latest"]' fallback applies and behaviour is byte-for-byte what
  it was.

No other job or workflow is touched; nothing else in the file changes.

Verification

The point of this change is the landing runner, not the diff. This PR's own tests
run is the check: gh api repos/scitex-ai/scitex-python/actions/runs/<id>/jobs --jq '.jobs[]|"\(.runner_name) \(.name) \(.conclusion)"' must report
scitex-0X-org-cpu-01, not GitHub Actions NNNN.

[ywatanabe1989]

Closed by the SciTeX 72-hour freshness policy: this PR had no activity for more than three days. PRs are perishable inventory and green evidence ages with the base. If the change is still needed, create a fresh PR from the current base rather than reviving this stale integration state.