Fix Java bridge crash on Android 17 (API 37) arm64

[Wes765]

On a Pixel 10 Pro XL running Android 17 (SDK 37, arm64), Java.perform()
SIGBUSes the target process. Two independent bugs are involved. Both
reproduce on a stock frida-server; neither is device-specific beyond the
new ART build, and both are fixed here.

1. ArtMethod access-flags offset detection

_getArtMethodSpec() locates ArtMethod.access_flags_ by masking the
runtime-only nterp flags off a probe method (Process.getElapsedCpuTime)
and matching against kAccPublic|kAccStatic|kAccFinal|kAccNative. The mask
stripped kAccNterpInvokeFastPathFlag but not
kAccNterpEntryPointFastPathFlag. On API 37 the probe method carries the
latter, so its real flags at offset 4 (0x50300119) no longer matched, and
the scan latched onto the next ArtMethod's flags one 32-byte stride over
(offset 36), corrupting the flag offset for every method.

Fix: also mask kAccNterpEntryPointFastPathFlag.

2. Unresolved literal pool in the thread-state-transition thunk

makeArtThreadStateTransitionImpl() recompiles art::JNI::ExceptionClear
and emits an invokeCallback subroutine whose
putCallAddressWithArguments() loads callback via a PC-relative literal
(±1 MiB reach). The literal pool was only emitted at writer.dispose(),
after the relocated ExceptionClear body. On Android 17 ExceptionClear
and the following function sit ~2 MiB apart, so the relocated body pushes
the pool out of the load's range, and it is left as ldr xN, #0, which
reads its own instruction bytes (0x...58000001) and branches to them,
giving a PC-alignment SIGBUS at the first withRunnableArtThread().

Fix: emit the invokeCallback subroutine first and flush the literal pool
immediately after it (it sits after a ret, so it is never executed),
then use the relocated transition body as the entrypoint.

Verification

Pixel 10 Pro XL, Android 17 (SDK 37): Java.use, static field reads,
method invocation, and method replacement (.implementation) all work.