ci: make the referenced windows-install-sqlite.bat exist and runnable

[metif12]

Summary

The windows-gcc job dies at its "Install SQLite" step, so Windows is not validated at all:

  .github/workflows/ci.yml (windows-gcc)
  - name: Install SQLite
  -   run: |
  -     .github\workflows\windows-install-sqlite.bat
  -     dir thirdparty\sqlite\
    - name: Build V
    -   run: ./make.bat -gcc
  + - name: Build V
  +   run: ./make.bat -gcc
  +
  + # Must come after "Build V": this used to run first, when neither `v`
  + # nor `v.exe` existed, so the referenced script could not work at all.
  + - name: Install SQLite
  +   run: .github\workflows\windows-install-sqlite.bat

The referenced script is not in the repository, and has never been:

$ git log --all --oneline -- .github/workflows/windows-install-sqlite.bat
(empty)

$ git ls-tree master .github/workflows/
100644 blob 4a68e6bf...  .github/workflows/ci.yml

The step also could not have worked even with the file present: it ran before "Build V", so neither v nor v.exe existed. Nothing in that step could have invoked V.

Evidence

Root cause, verified against the repository rather than the CI log (that run's logs are gone, HTTP 410):

$ git ls-tree master .github/workflows/
100644 blob 4a68e6bfd912b2cf917fd74a5d4098939b1db340   .github/workflows/ci.yml

The new script delegates to the downloader V already ships, which verifies both size and SHA3 rather than trusting a hand-pinned checksum:

assert zip_content.body.len == url_size
zip_shasum := sha3.sum256(zip_content.body.bytes()).hex()
assert zip_shasum == url_sha3

vlib/db/sqlite/install_thirdparty_sqlite.vsh chdirs to @VEXEROOT itself, so it installs into the thirdparty/sqlite the workflow then lists. YAML re-parses cleanly after the reorder:

YAML OK, jobs: ubuntu-gcc, macos-clang, windows-gcc, ubuntu-tcc

Also adds *.bat text=auto eol=crlf to .gitattributes, since batch files are only run by cmd.exe and were previously covered by no rule.

Not verified on a Windows runner — I have no way to execute GitHub Actions from here. The ordering argument and the git log/git ls-tree evidence are locally checkable; the runner behaviour is not.

Merge Danger

Door: Two-way. CI-only change; no product code, no schema, no data touched. Reverting restores the previous always-red job.

Blast Radius: Narrow, but the confidence is lower than the size suggests. Only windows-gcc changes behaviour, and it is currently red, so the realistic downside is that it fails differently rather than that something working breaks.

Two things a reviewer should weigh before merging:

• v run of a .vsh inside a Windows runner step is reasoned, not tested. If .\v.exe run rejects the .vsh path or the @VEXEROOT chdir lands somewhere unexpected, this step fails again with a different message.
• The windows-gcc job compiles with neither -d sqlite, -autofree, nor -prod, and runs no tests, while ubuntu-gcc runs all three plus the suite. So even once this step passes, the job still proves much less than the others. That gap is deliberate here and left out of this change, but it means "green windows" is not yet a meaningful signal.

This is also independent of #292, which fixes the actual compile failure.