PatchTargets
Which methods an install call names, and the matcher that reaches them. Split from Patch because it answers a different question: Patch decides what to weave INTO a method, this decides WHICH method.
Two paths, by whether the class is loaded — see Patch's class doc for why the loaded one is preferred and what it buys.
Functions
The nearest ancestor of target declaring a weavable method named in runtimeNames, with those methods. Abstract and native are dropped for the reason resolve drops them: naming one redirects the caller to a class that fails the same way. The interface closure is walked too — a default method carries bytecode.
Exactly the resolved methods, by runtime name + descriptor. Deduped because copies of one class on several loaders yield the same pair, and one term matches them all.
Class not loaded, so there is nothing to reflect over: fall back to forward name translation (one mojmap name maps to one runtime name per overload), narrowed by the wanted signature if there is one.
Why m may not be patched, or null. Each entry is on the path EVERY patch of that phase dispatches through, so weaving it breaks patches its installer never wrote — unlike a handler that loops back into its own target, which is the caller's. Keyed on the declaring class, which inheritance cannot route around: a box is INVOKESTATIC, and the wrappers are final and each declares its own accessor. The two names are JLS 5.1.7/5.1.8, so only the wrapper is looked up.
Veto, run last on what would actually be woven. All or nothing, since a name-only install weaves every overload — so the survivors are listed, which turns the refusal into a narrower retry rather than a dead end. Built here rather than in PatchDiagnostics: one call site, and refusal's reasons already are the diagnosis.