Correct actor-value virtual mappings

[Quantumyilmaz]

Summary

• make the two ActorValueOwner::ModActorValue overloads dispatch to their documented runtime slots under MSVC
• map the exact ABI of Actor::Unk_19D, the value-adjustment/clamping virtual used by the source-aware damage path

Why the declaration order changes

CommonLibSF correctly labels the source-aware overload as slot 0x06 and the no-source overload as slot 0x07. MSVC emits same-name virtual overload declarations in reverse vtable order, however, so the former textual order compiled calls to the opposite entries. Keeping the declarations reversed makes normal C++ calls use the documented runtime slots.

Actor virtual evidence

• PlayerCharacter::VTABLE[32] / ID 452459 is the ActorValueOwner subobject table at complete-object offset +0x70
• its source-aware slot 0x06 calls primary-table slot 0x19D for kDamage, passing (const ActorValueInfo&, float) and consuming an adjusted float return value
• PlayerCharacter::VTABLE[41] / ID 452447 is the primary table; its 0x19D override applies player/resource clamps and continues into the Actor implementation
• slot 0x07 is a no-source thunk that supplies a null source and dispatches slot 0x06
• the unknown method name is intentionally retained; only its proven ABI is mapped

Validation

• isolated MSVC codegen confirms no-source calls byte offset 0x38 / slot 0x07 and source-aware calls byte offset 0x30 / slot 0x06
• direct Starfield 1.16.244 vtable and call-site disassembly
• repo formatting and whitespace checks
• full CommonLibSF MSVC debug and release builds

QTR internal review draft. This has not been submitted upstream.

Integration check

All four QTR draft branches cherry-pick together cleanly, and the combined tree passes full CommonLibSF MSVC debug and release builds.