KmRemap
Rewrites a @Metadata proto so it agrees with the bytecode r just rewrote. One walk serves both directions: the direction is r's business and none of this walk's.
No direction flag, because member names go through Remapper.mapMethodName / Remapper.mapFieldName and ASM's base answers those with the name it was given — a class-only remapper opts out by not overriding them. The snippet weave does override them, and must: it renames an override in bytecode (getDescriptionId ->method_7876), and a proto still spelling the mojmap name is the same disagreement one level down.
Functions
The ClassName form of Remapper.map: metadata separates nested classes with '.' where bytecode uses '$', and a leading '.' marks a local class, which is never a mapped name. Null when unmapped — the identity a Remapper answers with instead is not a usable "no" for a caller that must leave the field untouched.
A type-use annotation has nowhere to live in the class file, so the proto is its only carrier — and its ARGUMENTS name classes just as its own type does.
else takes the literals, and whatever argument kind a later metadata version adds: passing one through costs a stale name inside an annotation, throwing on it would cost the whole class.
The type-bearing members of a class or package body — the shape openMembers walks for visibility, plus locals, the delegates declared inside a function body (val x by lazy {}), which carry a type of their own and reach the proto through no other list. The JVM signatures go too: they are what the backend and kotlin-reflect link against, so leaving them in the old namespace while the Kotlin types moved would split the two views of one member.
Rewrite every classifier reachable from t. Types nest through arguments, abbreviation, outer type and the flexible upper bound, so touching the classifier alone would miss most of a generic signature.