fix(pop3): wrap underlying errors

[mvanhorn]

What?

findAttachmentData in backend/pop3/pop3.go had three error sites that dropped underlying context:

• gomail.CreateReader returned an error but the wrapping call discarded it with a static "not a multipart message" string.
• The mr.NextPart() loop broke on a non-EOF error without saving it, so the final return at the bottom of the function reported "not found" instead of the real read failure.
• The not-found error had no count of how many parts the loop actually scanned, which made the failure hard to debug from a log line alone.

This PR wraps the CreateReader error with %w, captures the NextPart error in a local scanErr and surfaces it as the final error when it is set, and includes the scanned-parts count in the not-found message.

Why?

Fixes #688. The reporter noted the missing %w wrapping at the original line 438. While poking at that site I noticed the silent break on mr.NextPart() errors right above it. Those two paths share the same downstream "not found" return, so a multipart parse error in the middle of the stream looks identical to a genuinely missing part. The third change (scanned-parts count) is the smallest possible nudge that makes the two failure modes distinguishable in an error string without changing the return type or call sites.

The change is local to findAttachmentData and does not touch any caller. Existing tests in backend/pop3/pop3_test.go still pass; go build, go vet, and gofmt -l are clean.

Fixes #688

AI-assisted.

[floatpanebot]

Hi @mvanhorn! Please fix the following issues with your PR:

• Title: Is too long (55 characters). The PR title must be strictly under 40 characters.

Formatting issues have been resolved. Thank you!

[FromSi]

lgtm

[andrinoff]

lgtm