RFC: Handling passive Vulkan/DirectShow DLL locks in init-hook-files.c

[tonicofonico]

When a background process initializes Vulkan (e.g., RadeonSoftware.exe / AMDRSServ.exe loading obs-vulkan64.json as an implicit layer), graphics-hook64.dll stays mapped in memory with FILE_SHARE_READ | FILE_SHARE_DELETE. On the next OBS launch after an update, CopyFileW in frontend/updater/init-hook-files.c fails with ERROR_SHARING_VIOLATION (32) and leaves the stale hook in %PROGRAMDATA%\obs-studio-hook\.

Because init-hook-files.c normally runs non-elevated (just like its best-effort HKLM checks), MOVEFILE_DELAY_UNTIL_REBOOT cannot be relied upon to clean up renamed files since PendingFileRenameOperations requires administrator privileges. However, including DELETE in the add_aap_perms access mask allows standard non-elevated startups to both rename the locked DLL and clean up any previously unlocked .old file on subsequent launches:

static bool copy_hook_file(const wchar_t *src, const wchar_t *dst)
{
	wchar_t dst_old[MAX_PATH];
	if (SUCCEEDED(StringCbPrintfW(dst_old, sizeof(dst_old), L"%s.old", dst))) {
		DeleteFileW(dst_old);
	}

	if (CopyFileW(src, dst, false)) {
		return true;
	}

	DWORD err = GetLastError();
	if (err == ERROR_ACCESS_DENIED || err == ERROR_SHARING_VIOLATION ||
	    err == ERROR_USER_MAPPED_FILE || err == ERROR_LOCK_VIOLATION) {
		if (FAILED(StringCbPrintfW(dst_old, sizeof(dst_old), L"%s.old", dst))) {
			return false;
		}

		if (MoveFileExW(dst, dst_old, MOVEFILE_REPLACE_EXISTING)) {
			return CopyFileW(src, dst, false);
		}
	}

	return false;
}

(Paired with GENERIC_READ | GENERIC_WRITE | GENERIC_EXECUTE | DELETE in add_aap_perms).

Note that this only addresses the startup hook sync in obs-studio and is separate from the NSIS pre-install check in obsproject/bouf (extra/nsis/mp-installer.nsi returning exit code 6 when obs-virtualcam-module*.dll or graphics-hook*.dll are mapped by external processes).

Would a minimal PR with just this init-hook-files.c change be welcome, or are there any concerns where renaming an in-use hook DLL on startup could cause issues?