This codebase is very much tied to the win32 API, maybe with the winelib wrapper but otherwise I wouldn't bother.

Sibling post here mentioned using under wine but I'm not sure if that's the best idea since wine might not translate locking semantics in the same way and those might be plenty important to avoid corruption with SQLite databases.

SQLite is so very extremely popular that I don’t think you have to worry about corruption under Wine—if it was broken, a lot of software would be broken.

I'm not considering Wine emulation in isolation, I'm considering a scenario where someone would use this as a UI to inspect a SQLite database powering for example a Linux based NodeJS or PHP application.

Would the semantics of the Linux based application (with SQLite compiled for Linux) correspond to the UI (with SQLite compiled for Windows) running through an API emulation layer (Wine) that potentially translates semantics to run Windows applications as "natively" as possible.

Sure it might, but I wouldn't put money on it until verified. (Luckily backing up SQLite databases isn't too hard)

Ah, mixed Linux and Windows. Fair enough. Yeah, I’d assume that to be equivalent to a network share and accessing the database from multiple machines.

This has the intuitive scent of a project that works directly in Wine without any problems. Haven't tried it myself though.

Kinda like OpenMPT...indicate the supported Wine version in the Downloads maybe, and then after seeing it running just fine, one could argue that there's not even much point to a Linux port.

If it were written for Linux first, it would even be available for Windows simultaneously.

It would also be much more bloated (and not feel native) on Windows. Qt is what now? 30 or 50 MB? GTK probably much better these days. For that size you can almost go to Electron and get better look and feel (at the cost of RAM) ;-)

dbeaver is cross-platform and is a great general db client. I highly recommend it.