ci: remove the service-networking probe; scope the python-pin test

The probe's own log was never retrievable through the jobs API, but the
question it asked was answered better by a direct comparison of two real
workflows on the same runner and image:

  windy-git gate       @postgres:5432   -> passes its migration round-trip
  eternitas migrations @localhost:5432  -> failed

Also scopes test_g73 to workflows that actually run Python. It failed the probe
for not pinning a version when the probe only shelled out to psql — the test
being wrong rather than the workflow.

Co-Authored-By: Claude (Fable 5) <noreply@anthropic.com>

.gitea/workflows/service-networking-probe.yml

@@ -1,38 +0,0 @@
-# One-off experiment: how are service containers reached on THIS runner?
-#
-# GitHub-hosted runners port-map services to localhost. Gitea Actions runs the
-# job inside a container, so `localhost` is the job itself and services are
-# reached by their service NAME. Several migrated workflows hardcode
-# localhost:5432 — before rewriting any of them, prove which form actually
-# works here instead of assuming.
-name: service-networking-probe
-
-on:
-  workflow_dispatch:
-
-jobs:
-  probe:
-    runs-on: veron-1
-    timeout-minutes: 6
-    services:
-      postgres:
-        image: postgres:16-alpine
-        env:
-          POSTGRES_USER: probe
-          POSTGRES_PASSWORD: probe
-          POSTGRES_DB: probe
-        options: >-
-          --health-cmd "pg_isready -U probe"
-          --health-interval 5s
-          --health-retries 10
-    steps:
-      - name: which hostname reaches the service?
-        run: |
-          apt-get install -y postgresql-client >/dev/null 2>&1 || true
-          for host in localhost 127.0.0.1 postgres; do
-            if PGPASSWORD=probe psql -h "$host" -U probe -d probe -c 'SELECT 1' >/dev/null 2>&1; then
-              echo "RESULT $host = REACHABLE"
-            else
-              echo "RESULT $host = unreachable"
-            fi
-          done