Fix three Windows-only defects in OoT extraction

[briaguya0]

Three defects in the OoT factories that only manifest on Windows, found while integrating Torch into Ship of Harkinian as its asset pipeline (Shipwright#6989). Two are hard crashes; the third silently doubles the work and the archive.

All three are separator or bounds mistakes that are invisible on Linux and macOS, which is why OoT support looked fine — every extraction there produces identical output before and after this PR.

1. ParseAudioTable reads 64 KiB regardless of what is left in the segment

OoTAudioFactory.cpp:13 and :43 each built a BinaryReader over a fixed 0x10000 window at the table offset. MemoryStream's constructor copies the whole window up front, so the copy runs off the end of the decoded code segment when a table sits near it.

For PAL GC the sample bank table is at 0x1000B0 in a segment of 0x102250 bytes — 8,608 bytes available, 65,536 requested, 56,928 bytes over the end. glibc leaves those pages mapped so it goes unnoticed; on Windows the following page is often unmapped and it is an access violation that kills extraction:

memcpy_repmovs
LUS::MemoryStream::MemoryStream        lib/binarytools/MemoryStream.cpp:16
LUS::BinaryReader::BinaryReader        lib/binarytools/BinaryReader.cpp:8
OoT::OoTAudioFactory::ParseAudioTable  src/factories/oot/OoTAudioFactory.cpp:13
OoT::OoTAudioFactory::parse            src/factories/oot/OoTAudioFactory.cpp:95
Companion::ParseNode                   src/Companion.cpp:493

Reproducible on Linux under valgrind, which reports the first bad address as 0 bytes after a block of size 1,057,360.

Fixed by clamping each window to what remains in the segment. parse() already had codeDecoded.segment.size in hand.

2. Scene resource names carry backslashes

Companion::GetCurrentDirectory() returned gCurrentDirectory.string(), so on Windows the scene writer embedded native separators in exported resource names. Archive paths are always forward slash, so the game asks for a name that cannot exist:

scenes\nonmq\HIDAN_scene/HIDAN_scenePathwayList_0004AC6   what the scene asks for
scenes/nonmq/HIDAN_scene/HIDAN_scenePathwayList_0004AC6   what the archive contains

The lookup returns null and the consumer dereferences it. Rooms are mangled further, because WriteSetRoomList derives the base name with rfind('/') — which finds nothing in a backslash path, leaving the entire directory in sceneBase so it gets concatenated twice:

scenes\nonmq\bdan_scene/scenes\nonmq\bdan_room_0          Windows
scenes/nonmq/bdan_scene/bdan_room_0                       Linux

101 scene entries differed between platforms because of this.

GetCurrentDirectory was added in 4cae441 alongside the scene writer and has exactly one caller, so returning generic_string() affects nothing else.

3. external_files dependencies are keyed differently from the directory walk

The directory walk sets gCurrentFile from entry.path().generic_string() (Companion.cpp:1645); external_files built theirs with .string() (:547). On Windows those are two different strings for one file, so gProcessedFiles never matched and every file pulled in as a dependency was processed a second time:

	Windows before	Windows after	Linux
phase callbacks for 1450 ymls	2025	1450	1450
archive entries	42,119	35,411	35,411

gAddrMap is keyed the same way, so its lookups missed too — that is the source of the External File {} Not Found warnings.

The same commit fixes the "../" escape guard a few lines up, which compared against relative(...).string(). That is ..\ on Windows, so the guard never fired there.

These strings are only ever used as gAddrMap keys, as a path for LoadFile, and in error text, and outside Windows generic_string and string return the same value.

Verification

Extractions of a PAL GC rom, compared entry by entry by CRC:

• Linux output is unchanged by all three commits — 35,411 entries, identical CRCs, checked after each one.
• valgrind: 8 invalid-read contexts before, 0 after, no OoTAudioFactory frames remaining.
• Windows now matches Linux exactly — 35,411 entries, 33,154,599 bytes, every CRC identical. Before this PR it crashed mid-extraction; with only the first fix it completed but produced 42,119 entries with 101 differing scenes and crashed at scene load.

Happy to split this into three PRs if you would rather review them separately.