GeezerVison

…iled

Named proxies — Base.extend('a.b.C', {...}) and @javaproxy('a.b.C') — only
existed if the static binding generator had compiled them ahead of time:
ClassResolver routed com.tns.gen* names through DexFactory and threw for
everything else. SBG scans only assets/app, so a dev server that keeps
@nativescript/core off disk (Vite HMR serves it over HTTP) lost every named
proxy in core and crashed at boot with
LookedUpClassNotFound: Class "com.tns.FragmentClass" not found.

- ClassResolver: on LookedUpClassNotFound, fall through to DexFactory and
  generate the proxy dex at runtime — classes and interfaces alike. Logs a
  warning per class so SBG coverage gaps stay visible.
- DexFactory: tell named proxies apart from anonymous bindings so a dotted
  interface implementation keeps its requested name instead of the derived
  com.tns.gen one. Core's two @javaproxy proxies implement
  ActivityLifecycleCallbacks and ComponentCallbacks2 — both interfaces.
- ProxyGenerator: thumb-suffix dotted proxy file names. Unsuffixed files
  never matched getDexFile's probe (regenerated every launch), never
  matched purgeDexesByThumb, and jarFile.exists() reused their stale .jar
  across app versions.
- ModuleInternal: anchor relative runModule paths to the app root in the ES
  module branch, as the require branch always has — a generated binding's
  @JavaScriptImplementation carries a project-relative path (./bundle.mjs)
  that java.io.File flattens, and the ESM branch went straight to the
  filesystem from the process cwd.

Manifest-referenced classes (com.tns.NativeScriptActivity) resolve through
this path because the generated dex is injected into the app class loader
during entry evaluation — which the boot backstop holds until settled —
before the framework instantiates the activity. A precompiled class is
still the sturdier answer where a build step can provide one; this makes
the missing-class case survivable instead of fatal.

runModule now sends every entry through Module.resolveEntryPath: absolute
paths and URLs pass through, and a scheme-less relative name - the
@JavaScriptImplementation convention, ./bundle.mjs by SBG's stamp - goes
through the same resolution require uses, extension and directory probing
included, against the app root. A missing entry throws require's
"Failed to find module" from Java instead of a cwd-relative native stat
failure.

This replaces AnchorToAppRoot. Anchoring inside ModuleInternal::Load
resolved the load but not the identity: Runtime::RunModule probes the
boot backstop with the path it was handed ("Java resolves package.json's
main before handing the path over, so the entry the backstop probes is
the very one that was just evaluated"), so an anchored relative entry
evaluated under the app-root key while the backstop probed the unanchored
one - a registry miss that silently disarmed the hold and the rejection
fatal for exactly the dev-served entries this branch exists to support.
Resolving before the JNI crossing keeps one resolution seam and makes the
evaluated entry and the probed entry the same string by construction.

… primary

The dex cache key was name + thumb, and the thumb only changes on
reinstall - so once the thumb suffix made the cache actually hit, an
HMR edit to a proxy's method overrides would silently keep loading the
previous dex. The file name now also carries a digest of everything that
shapes the generated proxy besides its name: base class, interface flag,
and the sorted override and interface lists, so JS enumeration order
cannot cause a spurious miss. The digest sits after the thumb, so the
thumb-keyed purge keeps matching old generations.

When runtime generation itself fails, ClassResolver now rethrows the
original LookedUpClassNotFound with the generation failure attached as a
suppressed exception, instead of letting a downstream ClassNotFound or
ASM error replace the one message that names the class the app actually
asked for.