Git lfs manages everything client side, it uses smudge
and clean
filters when you pull/push files.
So if another developer pushe the same pdf file without using git-lfs as well you're in trouble as it will overwrite the pointer git-lfs replaces the actual file with in the git repo (you still have history though).
If that developer pushes a new pdf file without having git-lfs installed it will behave as git would normally do, pushing the binary into the git repo.
The versioning is handled by the backend (git backend not lfs) for the pointer itself, as it is now just text, but the client is responsible for reading the pointer and retrieving the correct blob from the lfs endpoint you specified in that repo's .git/config.
This behavior is independent from the lfs implementation you're using - currently the client also does not publish metadata with the blobs themselves so no way the backend can manage this.