fix: bundle sqlite3 lib for Windows cross-compilation

[Copilot]

Windows cross-compilation was failing at link time because libsqlite3.a (the import library generated via dlltool) was placed in winlibs/ — a directory not in the mingw linker's search path.

Changes

• release.yml — Windows libsql step: after generating libsqlite3.a, copy it to /usr/x86_64-w64-mingw32/lib/ so the cross-linker can resolve -lsqlite3
• release.yml — Build project step: copy sqlite3.dll into the release package directory alongside the .exe — required at runtime since libsqlite3.a is a dynamic import library, not a static archive

---

✨ Let Copilot coding agent set things up for you — coding agent works faster and does higher quality work when set up for your repo.

[lklimek]

🔍 Audit Summary

Reviewed by: Claudius the Magnificent (Claude Code) — solo review (PR too small to waste minions on)

Overall Assessment: ✅ Approve with minor suggestions

A correctly targeted fix for Windows cross-compilation. The two changes are logically sound:

1. Placing libsqlite3.a in the mingw linker search path so -lsqlite3 resolves at link time
2. Bundling sqlite3.dll alongside the .exe for runtime resolution

Findings

#	Severity	Location	Description
1	💡 Info	release.yml:118	Long single-line run command is hard to read; consider multi-line | block for maintainability
2	💡 Info	release.yml:118	libsqlite3.a is a dynamic import lib — correct that sqlite3.dll is now bundled at runtime. Consider documenting this linkage choice (dynamic vs bundled feature) somewhere for future maintainers
3	🟡 Low	release.yml:118	Hardcoded path /usr/x86_64-w64-mingw32/lib/ assumes Ubuntu runner layout. If GH Actions runners change base image, this could break silently. A dpkg -L mingw-w64-x86-64-dev | grep lib | head -1 lookup would be more robust, but acceptable for now

Pre-existing observations (outside diff scope)

• rusqlite in Cargo.toml does not use the bundled feature, confirming the project intentionally links against a system/external SQLite — consistent with this PR's approach
• The entire Windows libsql step (line 118) is a single 250+ char line. A future cleanup PR could break it into a multi-line script block for readability

✅ Positive observations

• Guard if [ -f winlibs/sqlite3.dll ] is defensive — won't break non-Windows builds
• Fix is minimal and surgical — only touches what's needed
• PR description clearly explains why both changes are needed (link-time vs runtime)

---

_{🤖 Reviewed by Claudius the Magnificent AI Agent}

[lklimek]

Clean, minimal fix. Both changes are correct — link-time lib placement and runtime DLL bundling.

Minor suggestions (non-blocking) in inline comments.

🤖 Reviewed by Claudius the Magnificent AI Agent