[medvednikov]

Summary

Fixes #27138: when a project contains a subdirectory with its own v.mod, importing a submodule like import dep.mymod from the outer project failed with unknown enum dep.mymod.Color (type_idx=0) and unknown function: dep.mymod.color_name. The dependency's .v files were parsed but registered under the wrong qualified name (mymod instead of dep.mymod), because the inner v.mod was treated as the naming boundary in util.qualify_module.

The fix anchors mod_path_to_full_name to the v.mod that contains the current compilation (pref.path). When the resolved module directory lies inside that project root, the module name is computed relative to it, so a nested v.mod no longer shrinks names of its sub-modules. The existing standalone case (`cd dep && v .`) is preserved — it's covered by test_running_project_from_its_own_vmod_with_parent_vmod_works_issue_26828, which still passes.

Test plan

• Reproduction from the issue now prints red / mymod.Point{...} / ok, with dep/v.mod present.
• Same reproduction still works after deleting dep/v.mod (no regression in the workaround path).
• Self-host: ./v -o v cmd/v runs cleanly for two iterations.
• vlib/v/tests/modules/ — 19/19 pass (includes sub/sub_test.v which uses a nested v.mod inside a submodule).
• vlib/v/tests/project_with_modules_having_submodules/ — 2/2 pass.
• vlib/v/tests/projects_that_should_compile_test.v — all pass, including new test_importing_submodule_through_nested_vmod_works_issue_27138 regression test.
• cmd/tools/vpm/ — 13/13 pass.