Fix Tool class override regression

[Pollux12]

Summary

• preserve the exact identity of planned direct page overrides across class alias groups
• emit a distinct canonical class.* override alongside a direct alias-page override
• reserve planned page overrides before output-file traversal to prevent order-dependent duplicate emission
• add multi-file regression coverage matching the real Tool / TOOL layout

Root cause

The structure de-duplication added for #8 used the canonical class name as a proxy for whether a page override had already been emitted. Tool and TOOL resolve to the same canonical class, but custom/class.Tool.lua and custom/TOOL.lua are separate overrides with different responsibilities. The direct TOOL override therefore caused the canonical Tool override to be dropped.

An initial identity-based correction also exposed an output-order problem: when structures.lua was processed before the planned tool.lua owner, the direct TOOL override could be emitted twice. The final implementation precomputes the exact planned override addresses before any output files are written, making emission independent of file order.

Impact

Generated tool.lua once again contains the Tool declaration and supporting types, so standard stool code can resolve methods such as self:GetOwner(), self:GetClientNumber(), and self:GetStage(). Direct structure overrides remain de-duplicated.

Validation

• npm test -- --runInBand __tests__/api-writer/glua-api-writer.spec.ts — 63 tests passed
• npm test -- --runInBand __tests__/custom-class-override.spec.ts __tests__/cli-generate-lua.spec.ts — 12 tests passed
• npm run typecheck
• real-data regeneration confirmed exactly one each of Tool, ToolObjectSlot, ToolObjects, Tool:GetOwner, TOOL.AddToMenu, HullTrace, SoundData, Trace, and EntityCopyData
• independent review exercised all five alias pairs in both registration orders and found no remaining actionable issues

Closes #14