context: resolve files whose names contain glob metacharacters (e.g. IMG_0347[1].jpg)

[OneSixForensics]

Summary

Context.get_source_file_path() silently fails to resolve any file whose name contains a glob metacharacter — [, ], *, or ?. These are common in real device data (e.g. IMG_0347[1].jpg, [clips4sale.com]clip.mp4), so affected files are dropped from artifacts and never linked/rendered.

Root cause

When multiple candidates share a basename, the resolver disambiguates with Path(candidate).match(partial_path). Path.match treats the argument as a glob pattern, so metacharacters in a real filename are interpreted as wildcards and the match fails — the file resolves to nothing.

for candidate in candidate_paths:
    if Path(candidate).match(partial_path):   # partial_path used as a glob
        return candidate
return None

Fix

• Single-candidate shortcut: when the basename maps to exactly one path, return it directly — no pattern match needed (the common case).
• Exact-suffix fallback: keep the existing Path.match for back-compat, then fall back to a literal normalized path-suffix comparison, which resolves any filename regardless of metacharacters.

Behavior is unchanged for all currently-working filenames; it only adds resolution for names that previously failed.

Context

Same bug and fix as abrignoni/RLEAPP#284 (root-cause discussion in abrignoni/RLEAPP#286). @JamesHabben confirmed it reproduces and the fix works in iLEAPP. In RLEAPP it was validated against a real ~32 GB return (17,214 device-backup files, many with bracketed names — all now resolve).