calc_ goes before leave_ in ForceSetCameraPos and InWaterSelForkASPlay,
and RailRoute's dtor goes after getCheckPointName (an unnamed row
there is likely its D0).

BaseProcJobHandler's ctor is linked right before BaseProc's ctor, so it
moves into actBaseProc.cpp, and the class moves into actBaseProc.h so
that its declaration stays with its definition.

(AI assisted using Claude Opus 5.5)

Each file moves to where its code is linked, and namespaces follow the
new paths. ASSettingMgr is an unofficial name.

| Old | New |
|---|---|
| act::ASSetting (ActorSystem/actASSetting) | res::ASSettingMgr (Resource/Actor/resResourceASSettingMgr) |
| Resource/resResourceASSetting, Resource/Actor/resResourceASResourceExtension | Resource/Actor/resResourceASSetting |
| ksys::DebugFinder (System/DebugFinder) | ksys::act::DebugFinder (ActorSystem/actDebugFinder) |
| ActorSystem/LOD/actLodState | ActorSystem/actLodState |
| ActorSystem/actAiRoot | ActorSystem/aiRootAi |
| Map/mapStagePreActorCache | System/StagePreActorCache (ksys) |

(AI assisted using Claude Fable 5.1 and Claude Opus 5.5)

A folder's files are linked before its subfolders, and the rigid body
files are linked as one flat sequence. ListShape is the one file that
does not fit this order.

| Old | New |
|---|---|
| RigidBody/Shape/<Kind>/phys<Kind>Shape.cpp | RigidBody/Shape/phys<Kind>Shape.cpp |
| RigidBody/Shape/<Kind>/phys<Kind>RigidBody.cpp | RigidBody/physRigidBody<Kind>.cpp |
| RigidBody/Shape/List/physListShapeRigidBody.cpp | RigidBody/physRigidBodyListShape.cpp |
| physHavokMemoryAllocator.cpp | System/physHavokMemoryAllocator.cpp |
| StaticCompound/physStaticCompound{,Mgr,RigidBodyGroup,Util}.cpp | System/ |
| StaticCompound/physStaticCompound{Info,Autogen}.cpp | System/physStaticCompoundInfo.cpp |

The original has the type infos' cleanup functions just before
StaticCompoundInfo's functions, so the merged file defines the
reflection data first, with plain static cleanup functions as in
Havok's generated reflection code. Template instantiations would be
emitted after the rest of the file.

(AI assisted using Claude Fable 5.1 and Claude Opus 5.5)

The 0x18-sized accessor appears to be named ActorLinkConstDataAccess
based on a source path string in the Wii U build. The 0x10-sized
base class (which we had given the name to) only holds a BaseProc and
its dtor/acquire functions live in a separate TU so let's rename it
BaseProcAccessor (unofficial name).

acquireActor is a header inline whose one copy landed in the BeamBase
object. Nothing in BeamBase calls it, so the BeamBase function that used
it was probably dead-stripped by the linker.

(AI assisted using Claude Opus 5.5)

aoc::Manager is created during engine start-up and called by gdt, map
and StarterPackMgr; only game code uses HardModeManager and
ChampionBalladManager.

(AI assisted using Claude Fable 5.1 and Claude Opus 5.5)

It is created only from game code, no engine code calls it, and it
hardcodes game actor names.

(AI assisted using Claude Fable 5.1 and Claude Opus 5.5)

setCamera's only caller passes the camera actor, a ksys::act::Actor;
ksys::act::Camera is only forward-declared.

(AI assisted using Claude Fable 5.1 and Claude Opus 5.5)

Keeps source and CSV from drifting from the IDB. Names are read from the
bodies, e.g. ActionBase::applyParams is what all 13 non-stub overrides
of that slot do.

(AI assisted using Claude Fable 5.1 and Claude Opus 5.5)