DuckDB cannot open its database on the Windows runner #109

The Windows job has been failing on bench-run's ClickBench integration tests since the Parquet autoload problem in front of it was fixed in #108. It gets further now and stops here.

the system starts: System { context: "opening C:\Users\RUNNER~1\AppData\Local\Temp\.tmpyPEj0v\duckdb\duckdb.db",
  source: DuckDBFailure(..., Some("IO Error: Cannot open file ...: The process cannot access the file because it
  is being used by another process.\n\nFile is already open in target\debug\deps\clickbench-....exe (PID 1056)")) }

Every test in that file makes its own tempfile::tempdir, so no two of them are pointing at the same path, and the same tests pass on the three unix targets. Whatever is happening is either DuckDB matching two different paths to one lock on Windows, where the temp directory arrives in its short name form, or nextest running two of these in parallel out of one binary and DuckDB naming the wrong holder.

Worth reproducing on the class B machine under Windows before guessing, since the two explanations point at different fixes. If it is the short name, canonicalising the scratch path before handing it to the driver settles it. If it is parallelism, the tests need a lock of their own rather than a nextest.toml that serialises the whole binary.

This is not a regression from #108. The job was red before it for a different reason and this failure was simply never reached.