Conform the invoker and the legacy-API guard to the interface

[JingMatrix]

XposedInterface promises, on Invoker and again on both getInvoker overloads, that invocations through an invoker bypass access checks. Ours only did so once the executable carried a hook: for anything unhooked, invokeOriginalMethod fell back to Method.invoke on the module's own reflected object, where ART runs the check it always runs and refuses every non-public member. The hooked case escaped only by accident, because LSPlant calls setAccessible on the backup it hands out.

invokeSpecial and newInstanceSpecial never read Invoker.Type at all, dispatching the live hooked ArtMethod whose entry point is LSPlant's trampoline, so the full chain ran whatever type the module had set, Type.Origin included. The argument handling beside it bore little relation to Method#invoke, which is what the invoker is documented against: any Number was taken for any numeric parameter and narrowed silently, reference arguments were never compared against the declared type, the receiver was never checked against the declaring class, and a static executable reaching CallNonvirtual or a Character unboxed through a Number method id took the process down rather than throwing. Both paths are now one primitive that dispatches through JNI, which performs no access control, after applying the receiver and argument rules reflection applies — the widening conversions of JLS 5.1.2 and nothing else, checked before the chain is entered so that a refusal of ours arrives unwrapped rather than inside an InvocationTargetException. The chain boundary also stopped collapsing a level of wrapping, so a target throwing an InvocationTargetException of its own now surfaces as ITE(ITE(x)).

One more followed from the same backup. An unhooked executable already dispatched through the receiver's vtable, but a hooked one is reached through a backup that ArtMethod::BackupTo makes private, so ART dispatches it directly and hooking a method quietly turned invoke into a non-virtual call: a Method taken from a superclass ran the superclass body where Method#invoke runs the override. The override is now resolved before dispatch, walking classes top-down so overriding stays transitive, comparing return types as well as parameters so a covariant override's bridge is not skipped, and confining package-private overriding to the same runtime package. Type.Origin deliberately does not resolve — skipping all hooks cannot mean entering one, and resolving there would send a hooker's own super call back into its hook.

The last is a question of scope. The behaviour change for modules targeting 102 names one package, and legacyApiPrefixes refused four, adding AndroidAppHelper and the XResources family; since API 102 carries no resource API of its own, that left such a module unable to touch resources at all rather than pointed at a modern route. Narrowing the guard made the path reachable and exposed three defects behind it: android_types.h bound the two ResStringPool::stringAt overloads to each other's signatures, so on any device exporting the modern one the call went out through an ABI-incompatible signature; resources_hook.cpp still read ResXMLTree at Android 9 field offsets; and XResources.isXmlCached compared an asset cookie against a resource id, so a shared XmlBlock was rewritten again on every inflation.

The conformance module this was checked against is on api102-harness. external/lsplant is rebased onto upstream in the same branch.