Is your feature request related to a problem? Please describe.
It's rather difficult to consider having any kind of in-game AI when you're unable to pathfind with it, a basic, even if rudimentary, Navmesh system for non-blocky Voxel Terrain probably has probably been long overdue and from what I've been able to research, there hasn't been particular progress as to making one.

Describe the solution you'd like
I've done a fair amount of research and considered one way of doing things that maybe would be acceptable in performance.
(Though I'm still unexperienced with both C++ and Godot Module development, so pardon if parts of this solution are not possible)

We begin when the Voxel Engine has just created the physics mesh (Or at the same time, using the same source) for a block in the terrain, we take that mesh and hand it to Godot, either to NavigationServer3D's bake_from_source_geometry_data, its async variant or with NavigationMeshGenerator's.
(This is assuming that calling these Godot methods are viable/performant)

Doing this we would get a NavigationMesh for this block of terrain but it wouldn't quite work just yet because of how agent_radius works. There's going to be a small margin to the borders of the physics mesh (where it would connect to other voxel blocks) so we will have to fix it.

We probably would save this result somewhere, so when the terrain is updated only a single block is parsed at a time instead of the whole terrain.

Finally, the navmesh is stitched to the other navmeshes, making a single one. We're assuming that there would only be one NavigationRegion3D or equivalent, thus, the feature it has for "automatically merging navmeshes with other regions" will not apply as this is all going to be inside a single region, additionally, overlapping navmeshes are very unpredictable in behavior, so merging is required.

In an ideal world, perhaps this merging step can be done in a similar fashion it is done when making the visual or physics mesh but maybe it will be necessary to make its own implementation for navmeshes.
And this is still mostly a "barebones" kind of implementation, as all the Navmesh would be:

• In one layer
• Only using one agent type
• Unable to consider things such as spherical planets (Though you could maybe change the "up" direction when baking a block)
• ..or any kind of wall climbing in the style of DRG's Glyphids (For this it could theoretically be possible to just pass the entire mesh as a raw navmesh, haven't done any research about this specifically)

But we've gotta start somewhere.

Describe alternatives you've considered
Firstly, I tried the obvious, try to use NavigationRegion3D on a VoxelLodTerrain... but it literally gave me nothing, then I've read other issues that talked about Navigation on non-blocky terrain here, but most of the "solutions" I've seen were either based on mostly static terrain, baked the entire terrain each time it was called (In addition of using 2 plugins) or finally requires the user to just "figure it out", while barely having the tools to properly have access to all of the critical voxel data to make a navigation mesh of some sort (And most of these issues are at least 2-3 years old).

Additional context
While I'm still learning C++, any indication of where I could search within the source code of the module to make a prototype of some sort would be appreciated. In addition of any observations/critiques/etc.

This is a great module for Godot, and I truly want to make some projects with it, but without any kind of Navigation for AI, it's losing out a lot.