[#100] Update SQLite to 3.53.3 to mitigate CVE-2025-6965

[SkowronskiAndrew]

Summary

Fixes #100.

This is a routine library update, getting a fix for a known security issue with past versions (but one that was extremely low risk for the way that UnityDataTools uses SQLite)

SQLitePCLRaw.lib.e_sqlite3 arrives transitively via Microsoft.Data.Sqlite, and the version we
shipped (2.1.10) bundles SQLite engine 3.46.1 — older than the 3.50.2 fix for
CVE-2025-6965. This bumps
Microsoft.Data.Sqlite from 9.0.1 to 9.0.20, which requires
SQLitePCLRaw.bundle_e_sqlite3 >= 2.1.12 and therefore resolves the native package to a build
carrying SQLite 3.53.3. That also clears the FTS5 memory-corruption CVEs fixed in 3.53.2.

Now that SQLite 3.53.3 has shipped we get the correct version without some of the explicit "pin" work that was described in the original task.

Practical exposure was always low: UnityDataTool is a local CLI that builds its own databases from
Unity build output and runs its own queries, so it never executes untrusted SQL from a network.
This is hygiene and clears dependency scanners.

Changes

Dependency

• Analyzer.csproj and ReferenceFinder.csproj: Microsoft.Data.Sqlite 9.0.1 → 9.0.20. These are
  the only two direct references; every other project picks it up transitively.
• Also normalised Microsoft.Data.SQLite → Microsoft.Data.Sqlite in Analyzer.csproj to match the
  real package id and the spelling in ReferenceFinder.csproj.

Double-quoted string literals

The reporter flagged that double-quoted string literals can break on a newer SQLite, and that turned
out to be exactly right — for a specific reason worth recording. The 2.1.10 native build does not set
SQLITE_DQS, so a double-quoted token that fails identifier lookup silently falls back to a string
literal. The 2.1.12 build is compiled with SQLITE_DQS=0, so that fallback is gone and such a
query is now a hard error.

• All 51 Analyzer/Resources/*.sql files were already clean — the only " characters are inside
  -- comments. Production C# SQL and the SQL examples in Documentation/ are clean too.
• Four literals in UnityDataTool.Tests/AddressablesBuildLayoutTests.cs were not, and failed with
  no such column: "buildlayout_2025.01.28.16.35.01.json" - should this be a string literal in single-quotes?. Converted to single quotes. A repo-wide sweep found no other occurrence.

Testing

dotnet build -c Release — succeeded, 0 warnings, 0 errors.

dotnet test -c Release — full suite green:

Project	Passed	Skipped	Failed
UnityFileSystem.Tests	435	10	0
Analyzer.Tests	62	0	0
UnityDataTool.Tests	288	0	0

No new tests; the existing analyze golden-database and find-refs tests are the right gate here,
since they execute essentially all of the tool's SQL and would surface any DQS=0 regression — as
they in fact did.

Verified the outcome rather than assuming it:

• dotnet list package --include-transitive reports SQLitePCLRaw.lib.e_sqlite3 2.1.12 in every
  project.
• The native library actually staged into the build output
  (UnityDataTool/bin/Release/net9.0/runtimes/win-x64/native/e_sqlite3.dll) reports SQLite
  3.53.3 and DQS=0.

Also checked the SQLite changelog for 3.47.0 → 3.53.4: no backwards-incompatible change affecting an
embedded application's SQL. The one documented incompatibility in that range (3.53.0, bare semicolons
after dot-commands) is sqlite3 CLI behaviour, not library behaviour.

One CVE remains open against 3.53.3 upstream (CVE-2026-50813, no released fix yet), but it is in the
Session Extension, which this tool does not use and cannot reach.