Limit PDB discovery to client binary directories

[HeresHavi]

Summary

Limited crash handler PDB discovery to the two directories where client binaries and their symbols are actually placed:

• The MTA installation root
• The MTA binary directory

Previously, PDB discovery recursively scanned the entire installation. This included mods/deathmatch/resources and every cached client resource, even though these directories do not normally contain client PDBs.

The new discovery helper checks only the known binary directories without entering nested folders. Regression tests verify that PDBs beside client binaries are detected while PDBs in resources and other nested directories are ignored.

Motivation

Crash handler initialization runs synchronously during client startup. CrashHandler::GetPdbDirectories started a recursive filesystem traversal from SharedUtil::GetMTAProcessBaseDir, which covers the complete MTA installation.

This means a large client resource cache adds filesystem work before the frontend appears. While this scan is running, the launcher can interpret the lack of visible startup progress as GTA being stuck and show the incorrect “GTA: San Andreas may not have launched correctly” warning described in #5096.

The amount of work scales mainly with the number of filesystem entries rather than their total size. Antivirus scanning, slower storage, or an uncached filesystem can make the same traversal considerably more expensive.

Client PDBs produced by the normal build are placed beside the launcher or directly inside MTA. Restricting discovery to those locations preserves local symbol support without scanning unrelated content.

This means PDBs placed in arbitrary nested directories are no longer discovered. That is intentional: nested resource and content directories are not part of the client binary layout and should not affect startup time.

Fixes #5096.

Profiling results

Created a resource test folder containing:

• 400 directories
• 400,000 sparse files
• 13,107,200,000 logical bytes (12.207 GiB)

Filesystem traversal results with the same dataset:

Before Fix: entries=405638 pdbs=0 elapsed_ms=316
After Fix:  entries=74     pdbs=0 elapsed_ms=0

The fixed traversal completed below the benchmark timer's one millisecond resolution.

This machine has a fast NVMe drive, so the original traversal did not reach the launcher watchdog timeout and the incorrect-launch dialog itself was not reproduced. The test did confirm that the old implementation entered the complete resource tree and that the fixed implementation does not.

Client launch validation:

• Before Fix: The original production client with the stress folder reached L3 closed after 14,060 ms.
• After Fix: A coherent development build with the same stress folder reached CreateDevice success after 6,277 ms and did not show the incorrect-launch warning.

The launch checks used different builds and milestones, so they are startup validation rather than a direct percentage comparison.

Test plan

Runtime

• Before Fix: Started the production client with the 12.207 GiB, 400,000-file resource folder present. PDB discovery visited the complete installation tree, including the resource folder.
• After Fix: Started a development client with the same resource folder. It reached CreateDevice success after 6,277 ms, and PDB discovery inspected only 74 entries in the two binary directories.
• Local symbols: Added PDBs beside the launcher and directly inside MTA. Both directories were detected.
• Nested symbols: Added PDBs inside mods/deathmatch/resources and a nested directory under MTA. Neither directory was returned by PDB discovery.
• Missing symbols: Verified that discovery returns an empty result when the two binary directories contain no PDBs.

Builds and Tests

• Debug | Win32: Full build passed, 306 client tests passed (304 existing tests and 2 new regression tests).
• Release | Win32: Full build passed.
• Debug | x64: Full build passed.
• Release | x64: Full build passed.
• Ran clang-format.

Checklist

• Your code should follow the coding guidelines.

• Smaller pull requests are easier to review. If your pull request is beefy, your pull request should be reviewable commit-by-commit.

[Dryxio]

Is Bin/mods/deathmatch intentionally excluded? Client Deathmatch also outputs its PDB there

[HeresHavi]

Is Bin/mods/deathmatch intentionally excluded? Client Deathmatch also outputs its PDB there

Not intentional. I just missed adding it back. The original issue was that it also descended into "mods/deathmatch/resources" which we don't want.