Some things to note first.. Project64 should absolutely not be used a reference to what the n64 should be doing. It has horrible accuracy. Mupen64 and any other derivatives like m64p, shouldn't be trusted for accuracy either, especially timing-related accuracy. Both PJ64 and mupen employ game-specific hacks and patches to attempt to run them (a real console doesn't do this). Also, keep in mind that the rate that a game runs on an emulator, can be different than how fast the emulator runs on your computer.
The definition of lag on the n64 doesn't really match other systems. And how that lag affects inputs can differ depending on how the game is programmed, in addition to any timing inaccuracies.
All official n64 games, except Namco Museum, use a part of the system called the RDP to generate each new frame of graphics, which gets saved to the system's shared memory (to one or more "framebuffers"). Separately, another part of the system called the Video Interface (VI), is (usually) periodically reading from the current framebuffer and outputting video data (e.g. to a TV screen).
To my knowledge most, if not all, games will use a double or triple buffer design. So the framebuffer that the VI is currently reading from, is swapped to the next, once the next image has been generated and saved. This usually happens after the VI reaches a certain (programmable) scanline, causing a "VI Interrupt". If the game logic, and/or the RDP takes too much time to generate the next frame, the framebuffer is not swapped, and thus the VI will re-output the same video frame.
Where do inputs come in.... This is where it gets tricky. Most games appear to poll controllers during the VI interrupt, regardless whether the framebuffer was swapped or not. So which poll does the game actually use? That's hard to tell without investigating the game logic. By contrast, a few games such as Super Mario 64, will instead poll for input based on its own game loop, which is why despite timing inaccuracies, it's very easy to console verify TASes for such games. Any timing differences between emulator and console don't really matter in regards to inputs; as long as the game logic still works the same.
The input lag you're experiencing could just be from inaccurate emulation, or the game itself simply is very laggy in regards to its game loop. My suggestion would be to try the
Ares emulator. Ares still has timing problems, overall it is much closer to how hardware behaves than the other emulators (cores) you've tried. Don't think the rando stuff is compatible, but at least you can use it to compare. If you still experience the same input lag, then I'd suspect it's just the game itself that's to blame. Or perhaps, something is still missing from all the emulators (which wouldn't surprise me).
