Basilisk ships no standard-library type information — stdlib recognition is name-only

Problem

Basilisk contains no type information for the Python standard library. What we call stdlib "resolution" is a compile-time list of module names (built from typeshed's VERSIONS file into a phf set) whose only job is suppressing imports_unresolved on lines like import os. No stub content for any stdlib module exists anywhere in the product — a stdlib import resolves to no file (resolved_path = None), so populate_imported_symbols skips it and every downstream consumer sees nothing.

Observable symptoms

• #289 (reopened): hovering Mock in session = Mock() renders only (import) from unittest.mock import MagicMock, Mock, patch — no class info, no constructor hint. The same holds for every symbol imported from the stdlib: Path, Thread, datetime, urlparse, …
• The only stdlib type knowledge in the product is a hand-maintained table of ~50 str method signatures added for #288 (builtin_members.rs). Curating the stdlib by hand one bug report at a time does not scale and guarantees repeat issues like #289.
• Our own spec and code claim stdlib type data exists when it does not: [STUBRES-TYPESHED] and the resolution table in CHECKER-STUB-RESOLUTION-SPEC.md describe typeshed stdlib stubs "bundled into basilisk-stubs", and the StubSource::Typeshed enum variant is documented as "bundled typeshed, compiled into the binary". The typeshed-path config exists to override a bundled default that isn't there.

What is blocked by this gap

Any feature that must know what a stdlib name is — hover signatures and constructor hints, signature help, completions on stdlib types, go-to-type-definition into the stdlib, and any future checker-side use of stdlib types.

What needs to be decided

The typing spec's import-resolution ordering (step 3) assumes checkers have stdlib typeshed stubs, noting they "will usually be vendored by type checkers" (https://typing.python.org/en/latest/spec/distributing.html#import-resolution-ordering). We need to answer, deliberately rather than by accident:

1. Do we need stdlib type data at all to meet the product bar ("one IDE extension for a complete, fast workflow"), and which features require it at what fidelity?
2. If we need it, where must the data live, given the constraints that actually bind us: deterministic out-of-the-box behavior, offline/air-gapped users, hermetic builds (make bench and CI do clean fresh builds), binary/repo size, license/attribution obligations of redistributing the data, and keeping the stubs refreshable against upstream.
3. If we decide we do NOT need it, [STUBRES-TYPESHED], StubSource::Typeshed, and the typeshed-path docs must be corrected to stop claiming a bundled stdlib source exists.

This issue deliberately specifies the problem only — no solution is prescribed here.

Refs #289, #288.