I can confirm Hippias Minor's problem - caused me some headache too. SQLite consists of a managed library that chooses which native DLL to load at run-time (either SQLite.Interop.DLL from x64 or x86 directory). This way it does not need to embed the native library (and is thus more portable - same "xcopy deployment" can work on different architectures). This is also the way SQLite is usually installed from NuGet.
The difference between "x86" and "Any CPU w/ prefer 32-bit" (beside being able to run on ARM) is that the first will set the environment variable PROCESSOR_ARCHITECTURE to "x86" while the second will set it to "AMD64"! The issue is described here: PROCESSOR_ARCHITECTURE returns AMD64 in some 32-bit processes
Therefore SQLite (which is using that as a heuristic) will try to load the 64-bit interop DLL and miserarbly fail since it is infact being run as a 32-bit process.
A workaround might be to check Environment.Is64BitProcess and when that is false manually change the environment variable to "x86".