Fix ANSI (PT_STRING8) text extraction: folder names, subjects, senders, bodies

[mekinney]

Problem

ANSI .pst files (Outlook 97-2002) are unreadable today: folder names and every message string property (subject, sender, body, …) come back empty, and WalkFolders aborts on the first folder.

ANSI stores text as PropertyTypeString8 (a code-page string) rather than the PropertyTypeString (UTF-16) used by Unicode PSTs. Two places assume Unicode:

1. Folder walk aborts. GetSubFolders reads PidTagDisplayName (prop 12289) with GetString(), which returns ErrPropertyTypeMismatch on a String8 value — aborting the entire walk on the first folder.

2. String values silently dropped on decode. The generated property structs key each text field by "<ID><Type>" using the Unicode string type 31 (e.g. Subject is msg:"5531"). WriteMessagePackValue writes a String8 value under a "<ID>30" key, which no struct field matches — so the value is read from the heap correctly and then dropped during msgp decode. Integer/time properties survive because their type is identical across ANSI and Unicode; only strings are affected.

Additionally, GetMessage reads PidTagMessageClass with GetString(), so on ANSI every item fails that read and falls back to properties.Message{} — misclassifying appointments/contacts.

Fix

• folder.go — branch on the actual property type for PidTagDisplayName: decode String8 via GetString8 (Windows-1252), else GetString. The walk no longer aborts on ANSI.
• property_reader.go — in WriteMessagePackValue, normalize the String8 message-pack key to the Unicode string type (31) so the value lands in the same struct field the Unicode path populates. Default String8 decoding to Windows-1252 (a superset of ASCII covering Western European text) rather than UTF-8.
• property_reader.go — add GetStringValue(), a type-agnostic getter (String or String8), for callers that don't control the PST format.
• message.go — read the message class via GetStringValue() so ANSI items classify correctly.

Windows-1252 is the pragmatic default; a fully correct implementation would honor PidTagMessageCodepage / PidTagInternetCodepage, but 1252 decodes the common case (ASCII + Western European) correctly and matches the existing folder-name path.

Test

Adds TestANSIStringProperties over the existing data/32-bit.pst (ANSI) sample, asserting that a PT_STRING8 PidTagSubject decodes to its expected text. The existing test suite still passes.

Notes

These two commits were developed for and validated by a downstream consumer (private-recall) against real ANSI archives — subjects, senders, sender emails, and bodies all extract; no regression on Unicode PSTs.