ci: Try collecting CPython-3.15 DLLs

[gaborbernat]

src/lib.rs has no (3, 15) match arm yet, and python315.def/python315t.def don't exist, so downstream crates (e.g. maturin-action consumers building Windows free-threaded wheels) can't target 3.15 at all. This mirrors e3183dd, which added the same two lines for 3.14 back when it was in beta: once this merges and the workflow is run (workflow_dispatch), update.yml's update-pythonxy job should pick up the new DLLs and open its usual Update pythonXY.def PR, after which src/lib.rs can get its own (3, 15) arm the way #94 did for 3.14.

3.15's ABI has been frozen since beta 1 (2026-05-07 per PEP 790), the same point at which 3.14 DLL collection started here (e3183dd), so this doesn't need to wait for the final release.

[davidhewitt]

@gaborbernat which downstream crate are you trying to build? Since PyO3 0.29 we replaced import lib generation via python3-dll-a with a built-in "raw-dylib" rustc feature, so updating this crate shouldn't be needed any more.

[gaborbernat]

Thanks for the pointer. Confirmed on our end: tox-dev/toml-fmt (the project that originally motivated this) is already on pyo3 0.29.3, and python3-dll-a doesn't even appear in its Cargo.lock despite enabling generate-import-lib — raw-dylib handles it now. Removing the Windows 3.15t skip and actually building confirms it: the wheel builds cleanly on both x64 and aarch64 with no import library at all.

So this crate isn't our blocker anymore; the comment that cited it was stale from before we upgraded pyo3. Closing this and #104 rather than taking up review time on something no longer needed on our end — figured you'd rather decide yourselves whether they're still worth finishing for consumers still on generate-import-lib/pre-0.29 pyo3, so didn't want to leave them open assuming that's wanted.