The problem is that network filesystems have some subtly broken semantics, especially in relation to locking, and that these problems are essentially inherent to how networking functions. This is because of the sheer number of potential weird failure modes, including some idiot unplugging a router in the middle of a commit in such a way that neither side of the connection can spot the problem for a while, or another device deciding to flood the network with packets such that comms become essentially impossible until the offending system is forcefully disconnected.
So the clarion logout timeout can help with some network failures, but you cant rely on db’s all having the same abilities. MS SQL has this COMMIT TRANSACTION (Transact-SQL) - SQL Server | Microsoft Learn
SQL Lite also has a commit.
Transaction (sqlite.org)
Commits should be handle.
On the point of a device flooding the network, an unmanaged switch should handle this automatically, but there will be noticeable disruption, it depends on what the factory settings are from a manufacturer. A managed switch if set up properly can prioritise the network traffic for db’s over the other devices. Its no different to traffic management seen in firewalls and home routers where gaming network traffic can have highest priority to avoid lag/latency in multiplayer online games. Same goes with teleconference and voip calls having high priority.
Sure in windows there is oplocks which breaks ISAM file’s but oplocks in windows was built in to allow office documents to be shared, once thats is switched off in the registry, its not really a problem for ISAM files but is for office documents.
Typical OS handling of networked filesystems provides no way to properly report these failures, or indeed any way to even do non-blocking access to files, so you instead get some very bad behaviours. (I remember losing a week of work back in the 1990s to a severely misbehaving NFS server that spent about 95% of the time in a crashed state with every process on my workstation — including the Xserver — blocked waiting to page in from the downed service.)
It looks like SQLlite3.dll is probably going to be like ISAM files from what I have seen, so if using a windows share, make sure oplocks is switched off.
If using on a linux share/NAS using something like Samba, then caching is off by default last time I looked.
There is also a few other options, sockets and ODBC.
SQLite CVSTrac
There is also this guide.
Appropriate Uses For SQLite
However there still is the logout and commit facilities in this driver so I dont know how you will fair trying this out. I also dont know what compilation options are in the version shipped by SV compared to the compile options described here.
How To Compile SQLite3.dll
There is also an ODBC driver for SQLite which would mean making sure the odbc ports are visible on the network and then it becomes more like a SQL server, or any other odbc connection, just make sure the network ports are not blocked by the firewall on the machine running the SQLite db. Same goes for the ports if using the sockets route, which is a bit more like a webserver then.
Network Database Access - ODBC API Reference | Microsoft Learn
I know a few people are using the ODBC driver to connect to postgres db’s, dont see why the same couldnt be done with SQLite, but just bear in mind, you might be pushing the technology in heavy use conditions.
SQLite Forum: ODBC 64bit drivers for windows download
SQLite ODBC Driver (ch-werner.de)
This link I think is showing how to connect the firefox web browser SQLite instance. I think MS Edge also uses SQLite as its browser db, ie bookmarks and other stuff.
Using ODBC to connect to SQLite (synametrics.com)
The other thing to consider is the replication route, ie each workstation having its own instance of the db, and then replicating with other sqlite db’s. This is something I havent tried and I dont know how robust it is or how fast it is, but Apple use this replication method to synch with their main db online.
Horses for courses as some would say. 
Edit.
One other thing thats worth checking is whether the SMB on the network is the latest for improved robustness and security.
I remember one of the ransomware attacks exploited a bug in SMBv1 EternalBlue - Wikipedia
ODBC uses SMB and CIFS so I would imagine it uses the SMBv2 and SMBv3. Sockets are direct tcp/ip just like a webserver and I dont know about the sqlite3.dll. It might only work on SMBv1 which is a no no because of the ransomware risk, but hopefully it will work with SMBv3, if not its ODBC or Sockets, which means nettalk territory (or even Replication if thats fast enough?).
I think it would be worth checking if TPS files also work on SMBv3 as well, just out of curiosity.
How to detect, enable and disable SMBv1, SMBv2, and SMBv3 in Windows | Microsoft Learn