Fix Android 16 ART Java bridge fast-path detection

[sec-staff-lilithgames]

Summary

• stop treating copied_methods_offset_ discovery as a hard initialization gate on Android 16 ART
• enumerate ART methods from the methods_ array header length instead of from copied_methods_offset_
• derive ART fast-path method and field modifiers from reflected getModifiers() instead of raw ART access flags

Why

On Android 16, Java.performNow() was failing during java/lang/Thread probing with:

Unable to find copied methods in java/lang/Thread; please file a bug

In downstream runtime debugging on a Pixel 8a / Android 16 device, the java/lang/Thread class object's methods_ array header length was 125, but there was no nearby u16/u32 == 125 candidate for the old heuristic. That lines up with current ART semantics where copied_methods_offset_ is a start index, not a total method count.

After bypassing that gate, the next failure was that Thread.currentThread() was being classified as an instance method on the ART fast path. Using reflected Method.getModifiers() / Field.getModifiers() instead of raw ART access flags fixed the dispatch kind.

Validation

Downstream, a repo-local bridge bundle built from these patched sources was exercised on com.android.purebilibili on both attach and spawn, and passed:

• static field access: Thread.MAX_PRIORITY
• static method resolution/call: Thread.currentThread()
• overload selection: String.valueOf(int)
• app context access via ActivityThread.currentApplication()
• Java.enumerateMethods
• Java.choose
• static hook replacement
• constructor hook replacement
• instance hook replacement on Thread.getName() and Application.getPackageName()

I also verified that the downstream existing demo/device baseline remained green after the fix.