lsp: completions offer items that don't resolve or shouldn't be shown

[0xGeorgii]

Follow-up from the comprehensive review of PR #239 (LSP server). Line numbers reference the PR branch at review time.

Severity: major (1), minor (2-4) — completions offer items that do not resolve or should not be shown. Verified empirically (probes + infs compile checks).

1. Bare names offered under a plain module import don't compile (completions.rs:147): with use lib; and pub fn exported() in lib, push_imported offers exported and the LSP layer inserts the bare label — but a Plain import binds only the module name: return exported(); fails with call to undefined function `exported` while lib::exported() compiles. Same over-offering for item imports (use lib::arith::{add}; offers ALL pub defs of arith bare, not just add). The unit test imported_module_and_its_public_defs_are_offered (completions.rs:450-457) currently encodes the broken expectation. Fix: label/insert the qualified form for plain imports (or drop bare entries), and for item imports offer bare only the braced names.
2. No ::-qualified completion context: after typing lib:: the general list (keywords, locals — 37 items) is returned; this is the one position where bare member names would be correct. Consider a dedicated context that offers the target module's pub defs.
3. Private methods of cross-module structs are offered (completions.rs:265): struct_members filters only by method_has_self, never visibility; accepting inserts a call the checker rejects with cannot access private method `hidden_m` on type `P` .
4. Completions inside comments and string literals (completions.rs:57): no token-context suppression; requesting inside // comment returns the full general list (35 items), and p. inside a comment returns 37. Editors that auto-trigger on typing will pop suggestions inside comments/strings.