ci(python): build Windows release wheel on 8-core runner (#4264)

Since #4241 restored fat LTO / 1 codegen unit for the Windows wheel, the
`windows` job in PyPI Publish has been cancelled at its 90-minute
timeout on every run, including the v0.40.0-beta.6 and v0.40.0-beta.7
tags, so neither release was published. In those runs dependency
compilation finishes after ~26 minutes and the `lancedb` crate compile +
fat-LTO step was still running after 63 minutes.

Move the job to the org's `windows-2025-8x-x64` larger runner and raise
the timeout to 150 minutes. Fat LTO stays, since the thin-LTO wheel
exceeds PyPI's 100 MiB limit.

The final fat-LTO step is largely single-threaded, so the gain from 8
cores is mainly in the parallel dependency phase plus faster/larger
hardware; the PR run of this workflow is the first measurement of fat
LTO on this runner.

.github/workflows/pypi-publish.yml

@@ -21,7 +21,7 @@ permissions:
   contents: read
 
 # Without this, a force-push to a PR leaves the previous run going -- including
-# a ~74 minute Windows job and a billed arm64 wheel build.
+# a long fat-LTO Windows job and a billed arm64 wheel build.
 concurrency:
   group: ${{ github.workflow }}-${{ github.event.pull_request.number || github.ref }}
   cancel-in-progress: true
@@ -123,8 +123,11 @@ jobs:
           path: target/wheels/lancedb-*.whl
           if-no-files-found: error
   windows:
-    timeout-minutes: 90
-    runs-on: windows-latest
+    # The fat-LTO build of the `lancedb` crate does not finish within 90 minutes
+    # on the 4-core standard runner, so use the 8-core larger runner with extra
+    # headroom.
+    timeout-minutes: 150
+    runs-on: windows-2025-8x-x64
     env:
       # link.exe is single-threaded and the long pole on Windows builds. Use
       # rustc's bundled lld-link instead.
@@ -145,7 +148,7 @@ jobs:
       # or the default branch -- so with no run on main there is nothing that
       # can populate an entry the release build would be allowed to read. Fixing
       # this needs a main/nightly trigger (which would also catch wheel-build
-      # breakage before a release); the ~74 minutes here is otherwise dominated
+      # breakage before a release); the build time here is otherwise dominated
       # by the fat-LTO link, which no cache avoids.
       - uses: ./.github/workflows/build_windows_wheel
         with: