Tolerate malformed part headers in multipart parsing

[mpasquale-3]

Summary

My Summary:

When there is an empty line in the header section, which is a malformed line, Apple Mail still renders the HTML perfectly. We need to parse equally permissively to effectively detect phishes. When there are malformed lines in the headers, skip them and see if you can still form a valid header with subsequent lines. Return the recovered parts along with the error so the caller can decide how to proceed.

🤖 Generated with Claude Code

[thunderkatz]

Since the original author is no longer with the team, picked this back up to close a gap before pulling it into go-mantis.

The removal of MalformedPartHeaderError in favor of a bare part != nil check breaks an implicit invariant every downstream caller relies on: today, a non-nil part alongside a non-nil error only ever means IsUnknownEncoding or IsUnknownCharset. Any caller with an error-classification cascade over those two (which is a common pattern) will silently mis-file the new malformed-header case into an "unexpected error" bucket instead of treating it as recoverable — verified this breaks two call sites in go-mantis (services/mdm and entity_utils/walk.go), both of which drop trailing sibling parts and misreport a benign quirk as an internal error.

Restored textproto.MalformedPartHeaderError / IsMalformedPartHeader, consistent with the existing IsUnknownEncoding/IsUnknownCharset pattern, and added a message.IsMalformedPartHeader forwarder so callers of the higher-level Entity/MultipartReader API don't need to import textproto directly. Entity.Walk now uses the typed check instead of part != nil. Added a TestWalk_malformedPartHeader test at the message package level to cover the forwarded case end-to-end.