fix(deps): pin patched heic fork to stop native decode memory leak

[frathe]

What does this change do, and why?

github.com/gen2brain/heic v0.7.1 leaks native libheif memory on every still-image decode (heif_decode_image without heif_image_release — gen2brain/heic#15). Go heap stays flat, so this is invisible to routine profiling but RSS grows without bound when browsing HEIC-heavy folders.

Upstream fix is in gen2brain/heic#16 (authored from this project) but not yet released. This PR adds a go.mod replace to frathe/heic@0ac0a39 (PR head), documents the pin in AGENTS.md, notes the mitigation in needs_refactoring.md, and adds an optional -tags=heicleak RSS regression test for manual/local use.

How was this tested?

• go list -m github.com/gen2brain/heic confirms replace → frathe/heic@0ac0a39
• go test -race -run 'TestLoadImage|TestReadMetadata_HEIC' ./internal/imaging/...
• PICFETCH_HEIC_LEAK_TEST=1 go test -tags=heicleak -run TestHEICDecode_DoesNotGrowRSSUnbounded ./internal/imaging/... (PASS on linux)
• make fmt-check, go vet ./..., go build ./...
• go test -timeout 20m -race ./... (all packages PASS)

Checklist

• make fmt-check is clean, go vet ./... and go test -timeout 20m -race ./... pass
• User-visible strings go through lang.L, with the key added to every bundle in translations/ (N/A — dependency/docs only)
• internal/ui/help/manual.md and manual_de.md updated, if this changes documented behavior (N/A)
• ARCHITECTURE.md updated, if this changes the package structure (N/A)
• No new TODO/FIXME comments — open items go in todos.md instead

Follow-up

Remove the replace and bump github.com/gen2brain/heic once upstream tags a release containing PR #16.

  

[cursor]

Cursor Bugbot has reviewed your changes using high effort and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit ac75135. Configure here.}

[cursor]

Unsigned subtraction wraps on RSS decrease causing false failure

Medium Severity

growth := rssAfter - rssMid operates on uint64 values. If RSS legitimately decreases between the two measurement points (e.g., the OS reclaims pages, or settleRSS releases memory from the first batch), the subtraction wraps around to a value near math.MaxUint64, which far exceeds maxGrowthMB*1024*1024. This causes a false test failure reporting "leak suspected" even when there is no leak. A signed comparison or an early-return when rssAfter <= rssMid would prevent the wrap.

 

^{Reviewed by Cursor Bugbot for commit ac75135. Configure here.}