Sorry for the confusing title, I'm not totally sure how to explain this. I'll do my best in layman's terms (which is all I know).

( At its core, this issue could be called an incompatibility with the pro version of the Physics Mod, but the effects apply to any mod that relies on knowing what chunks are currently loaded. )

For context, the pro version of the Physics Mod replaces the rendering of snow and water blocks with its own renderer. Essentially -- and I'm only making an educated guess -- the Physics mod "asks" Minecraft which chunks are currently rendered so that it knows where to render its physics stuff (the water and snow).

However, the physics mod is not rendering those elements on "Bobby Chunks." For example, ocean floors will render, but not the water.

The Farsight mod does not have this problem. Physics mod elements will render on "Farsight Chunks."

In the image below, I'm using Bobby alongside the Farsight mod with my render distance set to 24, on a server with a render distance of (16? Uncertain.). Notice how the water on the left half of the screen extends into the fog but only renders within server view distance on the right half of the screen.

As I'm sure you know, Farsight only keeps chunks in memory, your mod writes them to disk. The chunks seen in the image below were all loaded from Bobby's cache. The chunks on the left were explored with the Farsight mod installed and thus remain in memory.

To summarize, it appears Farsight tells the Minecraft client that its loaded cached chunks are loaded vanilla chunks, while Bobby tells the Minecraft client that its loaded cached chunks are separate. As a result, mods that rely on knowing what chunks are loaded (via asking the Minecraft client) are not aware that they can render inside "Bobby Chunks" as well.

Bobby's chunk's should already appear pretty much like Vanilla chunks (so long as you don't go snooping around in the chunk manager internals). If the server's lagging enough, you can actually walk right into them without even noticing.

The main thing it doesn't do however is emulating the chunk being received from the server (because that would just be unnecessary and make loading take potentially an order of magnitude more time). So if that physics mod doesn't query all the chunks within render distance every frame (which would allow it to see bobby-loaded chunks) but instead listens for the ChunkLoad packet to get incremental info on which chunks are loaded, then it won't see bobby chunks, and there's not a whole lot I can really do about that (at that point, might as well just use https://github.com/mircokroon/minecraft-world-downloader which also supports caching chunks on disk for an extended render distance and should work with pretty much everything, except maybe Immersive Portals).
Another thing it doesn't do is emit fabric-api's ChunkLoad/Unload events. This one's a lot more subjective, there isn't a technical reason it doesn't emit them (except that it'd be a tiny bit of extra work) but from looking at what all the mods I've been using are doing with the event, I've come to the conclusion that it's generally just a waste of time (and with some mods, a significant one) to fire it for fake chunks. If it turns out the physics mod uses these (which is by no means certain, given it also supports forge) to track active chunks, I'll happily add an option to enable them for bobby chunks as well (that offer also applies to any other mod that really needs them, if you can find one).

Though that's all just speculation because that physics mod appears to be proprietary, so I can't go and check what it actually does. You'll have to ask its author for details and/or to fix it.