I've done some experimentation here with a local VM and I'm wondering if you could try a few things for me.
The relevant item here is the protobuf-net.csproj.nuget.g.props inside the obj directory in the workspace on the grid node. This file contains the references to the Nuget package root used by the build system, and is the main way MSBuild finds the packages required to build the project.
When performing grid processing, NCrunch copies all required packages from the client machine over to the grid node, storing them in a fixed path (usually C:\NCrunch Grid Node\Snapshots\.nuget). The above .props file is then modified to point to the new package path on the grid node.
If you examine the above file, you'll see there are a couple of areas of interest. Firstly, we have the NuGetPackageRoot and NuGetPackageFolders properties. I note in the file you provided that these seem to be correctly repointed to the .nuget directory on the node. The second area of interest is the SourceRoot items. These seem to be a relatively new development in the platform and we don't have any logic in NCrunch that repoints these to paths on the node. However, in my own testing they don't seem to be relevant, as my VM can build the project even when these point to non-existent paths.
The first thing to try here is to run MSBuild.exe directly over the project as it exists in the NCrunch workspace on the grid node, without the /t:restore option used first. In theory, this should fail to build with the same error as that raised by NCrunch (if not, please let me know). This establishes a baseline for our known failure.
Next, you need to make selective modifications to the protobuf-net.csproj.nuget.g.props file to bring it into alignment with the file you sent me earlier when the build was working (after the /t:restore). I'm expecting that there is a specific thing in this file that when changed will solve the problem. You can run MSBuild.exe over the project as many times as you need to in order to deduct the source of this problem.
It's entirely possible that the problem isn't caused by something wrong in the protobuf-net.csproj.nuget.g.props file, in which case the next step will likely be to take a closer look at the packages stored in the .nuget directory to see if anything is missing.
Sorry, this is the process I would follow with troubleshooting this issue myself, but as none of our environments reproduce the issue, we need to do it this way.
