The strongest the README gets is saying "The LumoSQL and SQLite projects are cooperating", which is closer than any other effort I've seen, and welcome if the SQLite project ever wants to swap out the underlying storage engine, but doesn't really mean that the SQLite team "works on LumoSQL" or vice versa. Certainly it looks like LumoSQL has put significant work into the cooperation by using Fossil and by "not forking" which may have made the cooperation palatable.
Also, the SQLite project has been consistent on wanting to write all the code for SQLite themselves and not merge in patches (https://sqlite.org/copyright.html). Them working on another exploratory project would be a way for them to absorb those changes back into SQLite in a way that wouldn't be incompatible, but it would have to be the same team doing the changes for that to be consistent.
I see none of your claims being supported by your link.
It seems LumoSQL is just an umbrella term that refers to a bunch of patches applied over SQLite. I'm not sure if that's enough to not call it a fork.
Also,I saw zero references to the people actually involved in LumoSQL, other than the project being supported by the NLNet foundation.
I'd expect that a small project managed and hosted by the SQLite team to be hosted in www.sqlite.org, but this looks like a completely independent and unrelated effort.
This is obsolete documentation, retained only for historical reference. Do not consider anything on this page to be authoritative.
Implies this is old or abandoned, but I could not find any date information to validate that against.That last substantive edit to the document was in 2009. There were some spelling corrections in 2010. We finally got around to removing it from the documentation set in 2016.
Sorry about this misinformation, it looks like Sunday morning sleepiness got me.
It rather looks like LumoSQL is maintained by an independent group of engineers who seem to be quite familiar with the sqlite codebase and tooling.
At the time SQLightning greatly improved SQLite performance but due to LMDB's requirement to have keys fit in 2/3 of a page it wasn't really useful as a general purpose replacement of SQLite's internal b-tree implementation.
EDIT: It looks like SQLightning got adopted and has been worked on by the SQLite team under the name LumoSQL. Here's the project's readme: https://lumosql.org/src/lumosql/doc/trunk/README.md which contains at the end "A Brief History of LumoSQL"