Add a supported direct metadata API before completing resolver defaults

RE-VERIFY before continuing: these observations are from 2026-10-22 UTC. Read the current PR, branch heads and evidence first. No code from this lane was deployed or published.

The remaining work is a supported upstream SJVM metadata operation that can run on the caller coroutine while preserving inherited interface and registered override resolution. The resolver draft already implements interface defaults on absent members, but its queued metadata operation adds a reproducible stream regression. Publication and an upstream PR are outside the lane scope.

Owner context: https://github.com/CodexCoder21Organization/DigitalOceanDropletApi/pull/33 adds ageDataRecordedAtMillis with JVM interface default 0. A newer client reaching an older remote class needs that local interface default. The resolver PR opens with the exact owner provenance.

Established tests: root, returned, and required exact-text checks are red on main on all three attempts each. Restoring resolver source produces five attempt-1 passes. The older-client/newer-server and registered static override controls also pass immediately. Final pre-PR confirmation is 5/5 attempt-1 passes.

One complete suite ran from pushed source b58e784066bc71eecc28134e8884090ff06fa13b before rebase: 2403 scenarios, 2400 first-attempt passes, 2402 final passes, one final error, 2407 executions. All five new scenarios pass immediately. Main's rebase delta has no production source changes. Remote suite startup was unavailable, so the shared local slot was used. No second manual complete suite ran.

The exact remaining issue: tests/testRpcLogicInterruptedExceptionSurfacesAsSandboxException.kts:187 invokes getReadCalls after its stream reader interruption and close assertions complete. Main production passes the isolated scenario on attempt 1. Resolver default-member source repeats the 30-second invocation limit on all three attempts. The new remoteInstanceMemberAvailable lookup calls SJVM.withNewThread. That entry point starts work on SJVM's IO dispatcher limited to one task, behind guest stream computation still active there. The ordinary invokeVirtual path instead creates a thread and runs directly on its caller coroutine. The thread snapshot and dependency bytecode agree with this ordering.

Public API checks: LoadedClass.getVirtualMethod can read declared metadata, but full lookup also needs interfaces and registered overrides. Invoking the method as a probe runs its body; its NoSuchMethodError result has no origin marker that separates absent members from a body-thrown error. SJVMImpl thread construction is Kotlin-internal even though JVM signatures are public. A direct-construction experiment therefore did not compile and was removed; no source from it is included.

Next steps: add and test a supported upstream direct metadata API; obtain orchestrator scope for its separate PR/publication; update this resolver helper; verify existing stream scenario and all five default scenarios on attempt 1; run required final-head suite and CI. Preserve existing assertions, iteration counts and limits. Do not use a partial declared-method shortcut. Another lane FIXG owns gossip-send changes; do not touch that path.

Full findings: https://github.com/CodexCoder21Organization/UrlResolver/blob/wip/laneRDEF2-evidence/out/rRDEF2-findings.md . Detailed metadata analysis: https://github.com/CodexCoder21Organization/UrlResolver/blob/wip/laneRDEF2-evidence/out/rRDEF2-metadata-order-facts.md .

No merge, merge queue, Maven publication, production deployment, or production restart is authorized. The current draft must remain unmerged until the integration issue is corrected. All work has remote references; final findings record CI state and process cleanup.