MX will occasionally fail to find .mx_vcs_root in some circumstances

I might be in the wrong proposing this, but after I made this small edit, it fixed the problem for me.
I'm trying to set up a conan recipe for truffleruby (yeah i know its java and conan is for c++ but truffleruby supports the ruby C api and conan is a pretty nice way of managing C/C++ dependencies) and I was getting a really weird build error that did not make much sense, I was not getting the error building the recipe directly from the recipe's git repo, but I was getting it using conan install.

Conan install is a much more sandboxed environment that was likely messing with things causing the problem.
I decided to go through mx.py and see where it was trying to find .mx_vcs_root, and I noticed that it doesn't actually check if the directory starts with mx. (this is printing out current_dir)

After changing some lines around to check inside the mx dir that might be in current_dir, it fixed the problem.

                hocon = join(current_dir, 'ci.hocon')
                mx_vcs_root = join(current_dir, '.mx_vcs_root')

                hocon = join(current_dir, "mx", 'ci.hocon')
                mx_vcs_root = join(current_dir, "mx", '.mx_vcs_root')

Because I really don't understand how mx or any of the system revolving around it works, or even what these files are supposed to do, (I assume it marks where the mx git repo is?) I am unsure if this is intentional, or because this case happens so rarely nobody ever really tests it.
I'll assume it is the latter since when I tried a build straight from the truffleruby repository and patching mx.py, it worked fine.
I honestly don't really know what I am doing here, so I am probably wrong, but it's worth at least bringing the problem up.

Start in mx.py at the logic that searches for .mx_vcs_root and builds the ci.hocon path from current_dir. Reproduce the discrepancy between a direct truffleruby recipe build and conan install, then determine which directory should be checked in the sandboxed case. Done means the root is found reliably without breaking the direct-repository build.