Don't crash while reporting a bad liveness value (0.18.4)

[Treyo1928]

Same fix as PR #27, against the 0.18.x line.

This is the branch that matters for impact: version/v0_18_4 is the last beatsaber-hook 6.x release, which makes it the only line that runs on Beat Saber 1.40.8 — where this crash is actually hitting users today. The 0.18.5+ and 0.19.x lines moved to beatsaber-hook 7, and 0.20.x to 8, so none of them are installable there.

Unlike the master change, this one is build-verified and tested on hardware.

The bug

TraverseGCDescriptor's diagnostic fires when a traversed value looks corrupt, then dereferences that value's class pointer — via HasParentUnsafe, which reads klass->typeHierarchyDepth and indexes klass->typeHierarchy, and via logAll. Neither is guarded beyond a null check.

When the class pointer really is bad — the case the diagnostic exists to report — the report becomes a SIGSEGV on the AssetGarbageCollector thread. The log ends at Attempting HasParentUnsafe(...) with nothing after it, so the warning that says "THIS WILL CRASH" is itself the crash.

In one user's tombstones from Beat Saber 1.40.8, 18 of 40 crashes were this signature — the single most common cause, ahead of an unrelated beatsaber-hook issue at 16. Every one faulted at 0x00fffffffffffff8, which is exactly

klass->typeHierarchy[parent->typeHierarchyDepth - 1]

with typeHierarchy == NULL and a depth byte of 0, i.e. *(NULL - 8).

The game's own code tolerates these same values — disassembling the corresponding game path shows it reads a flag byte and skips. This diagnostic converts a condition the game handles safely into a hard crash.

The change

Add LooksLikeValidClass() — a real Il2CppClass points its klass field back at itself and has a name — and check both class pointers before dereferencing, logging which one looked wrong when skipping.

Everything already safe to dump is unchanged: the warning, the offending instance, its class and gc_desc, the field index, the value pointer, the traverse counters, and the logAll of obj.

Before (stock 0.18.4 — log ends here, process gone):

WARNING! THIS WILL CRASH, DUMPING SEMANTIC INFORMATION...
LivenessState::TraverseGCDescriptor(0x7241bd4b90, ...) class: ..., ::PlayerLevelStatsData
  with val: 0x72b12c14f0 (klass: 0x72b12c10f0), idx: 5
KLASS PTR: 0x72b12c10f0
Attempting HasParentUnsafe(0x72b12c10f0, 0xb40000725696f000)...
<SIGSEGV, fault addr 0x00fffffffffffff8, thread AssetGarbageCol>

After (same input, same repro):

WARNING! THIS WILL CRASH, DUMPING SEMANTIC INFORMATION...
LivenessState::TraverseGCDescriptor(0x7241bd4b90, ...) class: ..., ::PlayerLevelStatsData
  with val: 0x72b12c14f0 (klass: 0x72b12c10f0), idx: 5
has_references: false
obj_traverse_count: 198897 / generic_obj_traverse_count: 139591
KLASS PTR: 0x72b12c10f0
Class 0x72b12c10f0 of the offending instance is not a valid Il2CppClass,
  skipping the parent check and class dump
Continuing without crashing

Testing

Built against this branch (NDK 27, beatsaber-hook 6.x) and installed on a Quest 2 running Beat Saber 1.40.8. The condition is reproduced in memory by a test mod that builds a PlayerLevelStatsData whose _levelID points at an invalid object, then calls Resources.UnloadUnusedAssets() — no gameplay needed, and it never touches the save file.

build	result	diagnostic
stock 0.18.4	crashes every run	dies mid-dump
this PR	survives 4/4 runs	complete, every run

No new tombstones across the patched runs, and the field index the dump reports (idx: 5, _levelID) matches the original user's crashes.

Happy to share the repro mod, and a PC-only harness that replays the hook against the real Il2CppClass layout under qemu-aarch64 and reproduces the same fault address without a headset.

Not addressed

• What corrupts the value in the first place. Something frees PlayerLevelStatsData._levelID while the record stays live; that cause is still unknown. This only stops the reporting path being fatal.
• The filter offset. On this branch the filter is read from state + 0x10, and on 1.40.8 the LivenessState constructor stores it at +0x08 (+0x10 is process_array), so filterClass is usually not a class at all. Deliberately untouched here — the guard makes a wrong filter non-fatal without asserting what the right one is, and master already resolves this properly in liveness.cpp.