`import lib.X` silently resolves from the library root; SC0109 does not say which path was tried

A leading `lib` segment in an import path is special syntax: `classifyModulePath` (`src/Solcore/Frontend/Parser/Decl.hs:96-98`) strips it and resolves the rest from the library root. This appears to be undocumented, and the SC0109 diagnostic does not reveal it, which makes the failure genuinely hard to debug when a file physically exists at `/lib/X.solc`:

```
repro/
A.solc
lib/
helpers.solc
```

```js
// A.solc
import std.{*};
import std.dispatch.{*};
import lib.helpers.{*};

contract A {
constructor() {}
public function f() -> uint256 { return fortytwo(); }
}
```

```js
// lib/helpers.solc
import std.{*};

export {
fortytwo
};

function fortytwo() -> uint256 {
return uint256(42);
}
```

```
sol-core -f repro/A.solc --root repro
```
->
```
error[SC0109]: import lib.helpers: file not found
--> repro/A.solc:3:8
|
3 | import lib.helpers.{*};
| ^^^^^^^^^^^ module reference
help: check the module path or add the missing source file
```

The file the import names in the obvious reading (`repro/lib/helpers.solc`) exists; the candidate actually probed is `repro/helpers.solc`, but the diagnostic never says so. Moving the file to `repro/helpers.solc` (keeping `import lib.helpers`) compiles fine.

Seen on current main (1d490d8b, nix build).

Start with classifyModulePath in src/Solcore/Frontend/Parser/Decl.hs:96-98 and run the provided sol-core -f repro/A.solc --root repro reproduction. Trace the SC0109 diagnostic for the failed import and add coverage for the lib-prefixed path case. Done means the diagnostic identifies the candidate path that was probed while the existing successful resolution behavior remains intact.

Written by the indexing model from the issue text.