fix(modgraph): partition import resolves to base module, not own partition

[Sunrisepeak]

Summary

import :foo from a partition-interface unit (export module M:bar;)
was being resolved to M:bar:foo — the scanner prepended
provides->logicalName verbatim, which already contains the unit's
own :bar suffix. GCC's dyndep step still resolves the import
correctly (its own scan sees the right name), so builds succeed, but
mcpp prints

warning: <file>: module 'M:bar:foo' imported but not provided in this build

once for every such import. Reproduced under
mcpplibs/tinyhttps: seven
warnings per build.

Fix

 if (name.starts_with(":") && u.provides) {
-    name = u.provides->logicalName + name;
+    std::string base = u.provides->logicalName;
+    if (auto p = base.find(':'); p != std::string::npos) {
+        base.resize(p);
+    }
+    name = base + name;
 }

So for M:bar importing :foo we now produce M:foo (the sibling),
not M:bar:foo.

Coverage

Three new tests in test_modgraph.cpp:

• Scanner.PartitionImportFromPrimaryInterface — regression guard
• Scanner.PartitionImportFromAnotherPartition — the bug
• Scanner.PartitionImportWithDottedModuleName — xpkg-style names

Verification

• mcpp test — 9/9 unit binaries pass (incl. 3 new cases)
• mcpp build of mcpplibs/tinyhttps (which exercises the bug
  with 7 import :partition sites) is now warning-free
• CI green