easterbrooka/mike: Outlook .msg uploads added alongside .eml

easterbrooka extended the existing .eml ingestion path to cover Outlook's binary .msg format, mapping both onto a shared parsed-email shape so the viewer, the read_document tool, and the structure-tree extraction see no difference.

Outlook's .msg is an OLE compound document, not RFC 822, so the mailparser-based .eml handler couldn't read it. Rather than build a parallel viewer, easterbrooka wrote an adapter that normalizes a third-party msg reader's output into the same shape the .eml work produces: sender name plus address combined, recipients split into to/cc by recipient-type code, date ISO-parsed, attachments listed by filename without recursion into embedded OLE objects.

Downstream, everything treats both formats identically. The display endpoint serves .msg under the same internal content type as .eml. The frontend doesn't need a new viewer component. The supported-types list, upload modals, and drag-drop extension filters on the project page were widened to accept .msg.

Six unit tests cover the adapter's edge cases by mocking the underlying reader: missing headers, sender where name equals address, unparseable date strings, attachments with no filename. The PR merged with 117 backend tests passing and both backend and frontend type-checks clean.