Relative "from ..mylib.some import smth" was broken several versions ago

Basilisk 0.38.0, CLI, Linux x86_64. Though used through basilisk.nvim

Actual project path: /d/mypj/src/mypj/init.py

Minimal Setup

mkdir -p src/pkg/dev src/pkg/sub
touch src/pkg/__init__.py src/pkg/dev/__init__.py src/pkg/sub/__init__.py
echo "class Foo: pass" > src/pkg/sub/mod.py
echo "class Bar: pass" > src/pkg/dev/other.py

cat > pyproject.toml <<'EOF'
[tool.basilisk]
include = ["src/"]
EOF

Case 1 — single dot, same directory: PASSES

echo "from .other import Bar" > src/pkg/dev/user_dot.py
basilisk check src/pkg/dev/user_dot.py
# -> All checked. No issues found.

Case 2 — double dot, bare module target: FAILS

echo "from ..sub import mod" > src/pkg/dev/user_dotdot_direct.py
basilisk check src/pkg/dev/user_dotdot_direct.py
# -> error[imports_unresolved]: Cannot resolve import `sub`
#    = help: `sub` is not installed or has no type stubs

Case 3 — double dot, dotted attribute target: FAILS identically

echo "from ..sub.mod import Foo" > src/pkg/dev/user_dotdot_deep.py
basilisk check src/pkg/dev/user_dotdot_deep.py
# -> error[imports_unresolved]: Cannot resolve import `sub.mod`
#    = help: `sub` is not installed or has no type stubs

I'm at my wits end, no settings help to fix this.

Some analysis from codex:

• Confirmed: this is a Basilisk core bug, not a basilisk.nvim configuration issue.

  from .other import Bar passes accidentally: the resolver treats it as absolute other, then searches the importing file’s directory. For from ..sub import mod, the parser has already
  discarded the .. level, so it again tries absolute sub rather than searching the parent package directory.

  The repository already contains resolve_relative_import, including correct parent traversal, but the normal import pipeline never invokes it. The relevant gap is:

  - Basilisk/crates/basilisk-resolver/src/visitor/class_info_ext.rs:395 builds ImportInfo without preserving StmtImportFrom.level.
  - Basilisk/crates/basilisk-checker/src/imports/apply.rs:37 resolves every import through the absolute-import path.
  - Basilisk/crates/basilisk-checker/src/imports/resolve.rs:369 has the unused correct relative resolver.

  The appropriate fix is to add a relative_level field to ImportInfo, populate it from node.level, and dispatch From/Star imports with a nonzero level to resolve_relative_import. Add
  integration tests through resolve_module_imports for both issue cases—not just unit tests of the standalone resolver, which already pass and mask this wiring bug.

Start with Basilisk/crates/basilisk-resolver/src/visitor/class_info_ext.rs, then trace import handling in Basilisk/crates/basilisk-checker/src/imports/apply.rs and the existing resolver in resolve.rs. Run the supplied minimal setup and add integration coverage through resolve_module_imports for both double-dot cases; done means those imports resolve without errors.