Refuse to hook Object.getClass

[JingMatrix]

The minimal fix for #798, plus clearer messages for every refused hook.

A module hooked Object.getClass() and the launcher boot-looped. Since AGP 9 (#792), R8 turns
Kotlin's null checks into obj.getClass(), and the dispatch calls it entering every hooked method —
so a hook on getClass makes the dispatch call itself until the stack runs out. lsplant marks a
hooked method non-compilable and our dex is never compiled, so there is no way out at runtime.

getClass is the third method that can't be hooked, next to Method.invoke and
Constructor.newInstance, already refused for the same reason: the dispatch itself uses them. The
only difference is that the compiler, not the framework, is what calls getClass — which is why it
slipped through until AGP 9 put the call everywhere.

No module has a reason to hook Object.getClass. The one that hit this hooked every method named
getClass off Class.getMethods(), which always includes the inherited one, when it wanted a real
getClass override on another class. Refusing turns a boot loop into a HookFailedError the module
already catches.

Everything else the dispatch touches (Class.getName, Throwable.getCause, unboxing) stays hookable:
those are cold paths, called rarely, so they never recursed even before — only getClass is on the
path into every method.

This also rewrites the refusal messages so a developer sees why, not just that it failed, e.g.
"Object.getClass cannot be hooked: Vector's dispatch calls it entering every hooked method, so a
hook here would call itself forever."

An alternative that makes hooking getClass survivable instead — a dispatch guard, a native entry
point, VectorChain in Java — is #803. It is the general form but costs ~10% per dispatch and a
tricky invariant; left open for its analysis and its on-device test.

Verified on a Pixel 7a / Android 16: hooking getClass now fails at registration and every other
hook still runs with the process alive; on master the same module boot-loops.

Fixes #798.