Hardening: fix return-before-cleanup pattern in DownloadManager failure paths

[coderabbitai]

Summary

Early-return failure paths in EpicDownloadManager and GOGDownloadManager bypass important cleanup steps, potentially leaving stale state behind after a failed or cancelled download.

Problem

When downloadAndAssembleEpicChunks (or the analogous GOG function) returns a failure result early, the following cleanup is skipped:

• chunkCacheDir.deleteRecursively() — stale .chunks cache is left on disk
• MarkerUtils.removeMarker(installPath, Marker.DOWNLOAD_IN_PROGRESS_MARKER) — the download-in-progress marker is not cleared
• downloadInfo.setActive(false) — download info is not deactivated

This can cause the app to believe a download is still in progress on a subsequent launch, and wastes disk space with orphaned chunk cache files.

Affected Files

• app/src/main/java/app/gamenative/service/epic/EpicDownloadManager.kt — lines ~234-239 and ~370-373
• app/src/main/java/app/gamenative/service/gog/GOGDownloadManager.kt — similar pattern

Suggested Fix

Wrap the download-and-check logic in a try/finally block (or capture the Result in a local variable and perform cleanup after) so that regardless of downloadResult.isFailure or early returns, the following always runs:

1. .chunks cache cleanup (chunkCacheDir.deleteRecursively())
2. DOWNLOAD_IN_PROGRESS_MARKER removal
3. downloadInfo.setActive(false)

The same pattern should be applied consistently across all *DownloadManager files.

Context

This pre-existing pattern was identified during the streaming download PR (#1092, comment: #1092 (comment)) but is intentionally deferred to a dedicated cleanup/hardening review to avoid scope creep.

Requested by: @jeremybernstein