…both to a subprocess

Three questions an editor asks that only this server can answer correctly, and
that clients were spawning a CLI for:

`by/transpile` gives the python a document lowers to, or the basedpython a python
file reverses into. The difference from `by transpile <path>` is what it reads: a
subprocess reads the file, and an editor's copy of a file is the buffer. Asking
about a document with unsaved edits returned the last saved version of it, which
is the wrong answer and a silent one. Answering here also transpiles against the
project db the session already holds, so cross-module types resolve and the result
cannot disagree with the diagnostics in the same window.

`by/explainRule` and `buff/explainRule` give the documentation for one rule. Two
tools own two disjoint sets of rules and neither knows the other's, so each answers
for its own and reports a miss — not an error — for a name it does not have,
leaving the client free to ask the other.

Both renderers moved down into the crates that own the rules, so `by explain rule`,
`buff rule` and the editor all show one rendering rather than three that drift.

A transpile that fails travels as a result carrying the reason, not as a protocol
error: source that does not lower yet is an ordinary state for a file being edited.

…r than from the text

`by/explainTranspilation` reports every basedpython-specific construct in a
document and what each lowers to. A client that wanted this had to guess from the
source text — one regex for `?.`, another for `??`, another for `data class` —
and a regex cannot tell an operator from the same characters inside a string or a
comment, cannot see that `?` in a type position means something else, and drifts
from the language the moment a construct is added.

The parser here is the one the transpiler runs, so the answer is the one the
lowering is about to act on. `?.` in particular is not looked for at all: the
parser records it as a flag on the access, so this reports what was written
rather than what the characters resemble.

`by/transpile` also takes a fragment now. A selection has no document of its own,
and the alternative — writing it to a temp file and running the CLI over that —
is the thing the request exists to remove; the document it names is only what
routes the request to a server.

the digests had no consumer: the shim read SOURCEMAP alone, and by build
wrote no map at all — so the check existed where a map lives for one run,
and not where one outlives the build that wrote it

the traceback shim refuses a mapping its digests no longer vouch for

`run`, `build`, `transpile` and `compile` check on the thread they were
dispatched to rather than through the rayon pool, and that thread got
whatever stack the platform starts a process with — 1 MiB on windows,
where checking a file that nests deeply enough overflowed it

renaming `util.by` to `helpers.by` renames the module `alpha.util`, and every
`from alpha.util import thing` in the project is now naming a module that is
not there. an editor cannot find those on its own: it would have to resolve
every import against the same search paths the checker uses. so the protocol
has it ask first, and the server had no answer — `workspace/willRenameFiles`
was never advertised, and `rename` is a symbol rename that refuses an import's
module component outright.

the request is now handled. it arrives before the file moves, which is what
makes it answerable at all: the old path still holds the file, so the module it
is today resolves, while the new path is a path to read a name out of. that is
the one thing `file_to_module` cannot do — it resolves the name it derives back
to a file and checks the answer is the same file, which nothing at the new path
can satisfy — so `path_to_module_name` answers the narrower, purely
path-shaped question, for directories as well as files.

what is rewritten is the module paths in import statements, at any depth in the
file (an `if TYPE_CHECKING:` import is exactly the one written carefully), and
the *uses* of a name an import binds when that name changes: `import alpha.util`
binds `alpha`, so `alpha.util.thing()` moves too. those uses are found by their
text and confirmed by their type — an expression is only rewritten when the
checker says it is the module that moved, so a local called `util` in a file
that also imports a module of that name is left alone.

a relative import inside a package that is being renamed as a whole comes out
unchanged, which is the truth: the dots go on meaning the file's own package,
and that package is moving with it.

two things are deliberately not rewritten, and both are reported rather than
half-done: a module named as a string, and an import that would have to change
shape — moving `alpha.util` to `beta.util` leaves `from alpha import util`
needing a different statement, not a different word.

folders are asked about as well as files, because renaming a directory renames
every module under it and the client sends only the directory. a folder pattern
cannot be narrowed the way the file one is — a directory has no extension, and
whether it is a package is a question about the search paths — so every folder
rename costs one request that usually answers with no edits.

name a path by the deepest search path that contains it

caught by driving the server against a real uv workspace. the member's
package sits inside two search paths at once — the project root, and the
editable entry uv writes for the member itself, pointing at its own `src`
— and taking the first one consulted named `packages/alpha/src/alpha` as
`packages.alpha.src.alpha`. that is not a module anything imports and not
the name any `import alpha` resolves to, so a rename of it found nothing to
rewrite and answered no edits at all.

the deepest search path is the one whose name resolves back to the path,
which is what `file_to_module` verifies for a file that exists. with the
rule fixed, the same workspace answers with all three edits: the `from
alpha import thing`, the `import alpha`, and the `alpha.thing()` in the
body.