PR #684: Restore container drive mappings and stop emitting unresolvable Z: paths

PR #684

Title: Restore container drive mappings and stop emitting unresolvable Z: paths

Author: @maxjivi05

Source PR: WinNative-Emu/WinNative#684
Source branch: fix/container-drive-mapping
Source commit: f49247e72017835b9a128070ccdafd498b1eb6e7
Build workflow run: https://github.com/WinNative-Emu/WinNative/actions/runs/31648756632

What This PR Is About

Since #674 dosdevices was the only source of truth for drive letters: createDosdevicesSymlinks read the prefix, applied exactly that set and deleted every other letter, and only consulted the container config when the prefix had no drives at all. A container whose prefix had lost f: -- the internal-storage mapping -- could therefore never get F: back even though .container still listed it, so the drive stayed missing on every later boot.

Boot now applies the union of the container config and the prefix, so a configured drive is always recreated while a drive added inside winecfg is kept and persisted back into the config. A drive removed in container settings is written out of both, so it still stays removed. Containers whose config itself lost the platform defaults get them re-added once, guarded by driveDefaultsRestored so the repair cannot fight later edits.

The missing F: also broke custom game shortcuts. Since #544 custom games launch from their real install path, which needs a drive letter covering it; with none, hostPathToMappedWinePath fell through to "Z:" plus the absolute android path. z: points at the imagefs root, not /, so that path cannot resolve and wine reported "Path not found". Path mapping now reports when nothing covers a path, and custom game launch falls back to the container's C:\WinNative\Games link, which always resolves.

Attached Artifacts

• WinNative-Debug-Standard-PR.684-f4924.apk
• WinNative-Debug-Ludashi-PR.684-f4924.apk
• WinNative-Debug-Pubg-PR.684-f4924.apk
• WinNative-Debug-Antutu-PR.684-f4924.apk

Built from source commit f4924.