roadmap: record the extern import-prefix bug

[simontreanor]

Reported from the dogfooded app. Recorded as dogfooding finding #7 rather than fixed, per the instruction to look at it after the current sweep.

A dotted extern target emits the wrong import when a lowercase segment is an object rather than a submodule. lowering::extern_import takes the maximal leading run of lowercase-initial segments, following PEP 8, so it works exactly when that run happens to be a real module:

target	emitted	outcome
pathlib.Path.write_text	import pathlib	works, Path is capitalised so the run stops
os.path.join	import os.path	works, os.path really is a submodule
sys.stdout.flush	import sys.stdout	fails, stdout is an object

The emitted call is always correct; only the import line is wrong.

There is a working workaround today, verified: extern import sys is consulted before the heuristic and emits import sys, after which sys.stdout.flush resolves. Worth knowing while the fix waits.

The suggested fix needs amending. "Import the longest importable prefix" is not statically decidable — whether urllib.request or sys.stdout is a module is a property of the target environment, not of the text. "Always import the top-level package" only trades one broken case for another; verified on CPython 3.14:

import urllib  →  urllib.request   AttributeError
import os      →  os.path.join     works
import sys     →  sys.stdout.flush works

So the entry records three candidates instead: a guarded deeper import (try/except ImportError, correct everywhere, mildly ugly, once per module); rejecting the ambiguous shape at compile time with a fix-it naming the extern import to add (fits "the compiler is the gatekeeper", no runtime cost); or both.

Docs only.