fix(gui): dedicated Path Mappings icon, launch on double-click in Shared Files and completed Downloads - #868

Built and ran it on macOS (wx 3.3.3) — the icon embeds and resolves, and I rendered the sidebar set at 16/32/128 for the visual check you flagged as not done.

1. The double-click gate does the opposite of what its comment says.

FileLaunch::CanOpen() is only "path resolves and the file exists" — it isn't type-restricted. The media filter in CDownloadListCtrl::OnItemActivated comes entirely from CPartFile::PreviewAvailable() (PartFile.cpp:4461):

return (type == ftVideo || type == ftAudio) && GetFileSize() >= minSizeForPreview &&
       IsComplete(0, minSizeForPreview);

So the Downloads double-click is video/audio only. With previewable = file->IsPartFile() ? PreviewAvailable() : true, a completed shared file of any type opens — including the .exe the comment says it avoids handing over. Three claims don't hold:

• "Mirrors CDownloadListCtrl::OnItemActivated" — that one is media-only, this is any-type.
• "the same gate this file's own MP_VIEW context-menu entry already uses" — CSharedFilesCtrl::OnOpenFile has no gate at all; it calls FileLaunch::Open() unconditionally.
• the inline comment's "it stays media-only rather than handing a just-finished .exe to the platform opener silently".

Fix: keep the any-type behaviour here, and bring Downloads in line in the same PR so the two really do match. CPartFile::IsPartFile() is already exactly "not complete" (status != PS_COMPLETE, PartFile.h:124), so it's one line:

-	if (file->PreviewAvailable() && FileLaunch::CanOpen(file)) {
+	if ((!file->IsPartFile() || file->PreviewAvailable()) && FileLaunch::CanOpen(file)) {

That is the same condition this PR already writes for shared files — !IsPartFile() || PreviewAvailable() — so both panels end up with one rule: a completed file opens whatever it is, an unfinished one only once enough media is on disk to play. The comments in both places should say that; the current "media-only" framing describes neither.

2. The badge is illegible at 16px. r="4" in a 16×16 viewBox is 8px across, and the arrows inside collapse to a gold disc at 1× — they only resolve from 32px up. It also overhangs the folder silhouette at the bottom right.

Fix: r="3.2", pull it inside the folder bounds, and raise the arrow stroke from 0.9 to ~1.1 so it survives downscaling. Optional — the colour change alone already answers what was raised in #843.

Since the Downloads change brings in a second panel, the title and body want widening to match — something like "launch on double-click in Shared Files and completed Downloads".

Pushed 76bd438 with both findings addressed, sitting on top of your rebase — your commit is untouched, and the branch is on current master (past #877 and #882).

1. The gate. Kept the any-type behaviour here and brought Downloads in line, so the two panels really do match:

-	if (file->PreviewAvailable() && FileLaunch::CanOpen(file)) {
+	if ((!file->IsPartFile() || file->PreviewAvailable()) && FileLaunch::CanOpen(file)) {

Both panels now read !IsPartFile() || PreviewAvailable(): a completed file opens whatever it is, an unfinished one only once enough of the media is on disk to play. Worth noting why this is the direction to fix it in rather than narrowing Shared Files — a download that has just completed is listed in both panels at once, so a double-click meant two different things on the same file depending on which tab you were looking at. Both comments are rewritten to describe the rule they implement; the old ones described neither.

2. The badge. My suggested fix was wrong — I rendered it before applying it. At r="3.2" with a 1.1 stroke the arrows still collapse: in a 16×16 viewBox the disc is barely 7px across, and two separate arcs can't resolve at that size at any stroke weight. The glyph is now a single double-headed arrow, one shaft with a head at each end, in white rather than dark brown (a dark outline on amber greys out at 1×). Disc is r="3.4", pulled back inside the folder bounds. It reads at 16px and stays clean at 32px; icon_data.c regenerated with the exact command icons.yml diffs against.

Gates on the final tree: clang-format v18 whole-file clean, Tier-2 clang-tidy clean with 0 compiler errors, macOS build clean with no new warnings from the changed files. The icon is confirmed live in the Preferences sidebar in a running amuleGUI, which closes the one item your test plan left open.

I've widened the title to cover the second panel. The body's third bullet I've left for you rather than rewriting your description.