My interpretation:
You don’t have cached metadata in your specified --find-links folder, only the cached tarball. When Pip tries to build the package, it doesn’t care about the filename for the tarball - it only gets metadata either from a separate metadata file, or from the build process.
as can be seen on GitHub, the pyproject.toml file doesn’t specify a version number. pyproject.toml is in fact quite minimal in this case; it’s only specifying some build dependencies, and expecting the setup.py process to create all the needed metadata.
But this project wants to compute the version using setuptools-scm, an extension to setuptools that checks version control to retrieve information about the project and compute things like the version number.
More specifically, it’s configured to use setuptools-scm to write a version number into a lz4/version.py file in the source directory, and then use that during building to set the version for metadata. (The file is then also available for the program to use internally at runtime.) The GitHub repository doesn’t contain this file (version control wouldn’t be tracking it on the devs’ machine) and neither does the source tarball. This is a problem, because it prevents anyone else from building from the source tarball - when unpacked on someone else’s machine, there’s no Git repo from which to extract the version info.
So when the package is built from the sdist, it can’t produce the necessary file, therefore can’t inform the metadata creation process, and therefore falls back to a default version number.
The documentation proposes that it should be possible for users to build from the sdist, so this can reasonably be considered a bug to report on the issue tracker (if it isn’t there already). For now, please use a wheel instead if at all possible.
Just for the record (it doesn’t appear to relate to the problem), using --no-index --find-links= is the opposite of that: it’s forcing Pip to use a local copy of the lz4 component, rather than checking PyPI for any updates.