[Enhancement]: Drag-and-drop on document-capable providers (Bedrock) ignores a configured supportedMimeTypes; and .msg has no extension mapping

[skinzman]

What features would you like to see added?

Summary. On a Bedrock endpoint (and on the other document-supported providers),
a file dragged onto the composer is accepted only if its type starts with image/ or
is one of the provider's document types. The admin's fileConfig.endpoints.<key>.supportedMimeTypes
is not consulted on that path, although it is consulted by the paperclip. So an admin
who widens the allowlist to admit, say, message/rfc822 gets it admitted through the
paperclip and refused on a drag, with the toast "This file type can't be attached
here". Separately, Outlook .msg files arrive from Windows browsers with an empty
File.type, and inferMimeType has no msg entry, so they cannot be admitted at
all.

Where (current main).

• client/src/utils/files.ts, isProviderAttachType: for a custom endpoint with a
  permissive configured list the function returns checkType(type, ctx.endpointSupportedMimeTypes);
  for Bedrock it returns type.startsWith('image/') || isBedrockDocumentType(type)
  and never looks at the configured list.
• client/src/utils/files.ts, getViableUploadOptions: if (types.some((type) => !type)) return [];
  so an empty inferred type is refused before any list is consulted (correct, but it
  makes the mapping below necessary).
• packages/data-provider/src/file-config.ts, codeTypeMapping: carries
  eml: 'message/rfc822' and no msg entry; applicationMimeTypes carries
  message/rfc822 and not application/vnd.ms-outlook.
• The paperclip's accept attribute also excludes email, so the OS file dialog hides
  .eml unless the user switches the filter to All Files.

Proposal.

1. In isProviderAttachType, when the admin has configured supportedMimeTypes for
   the endpoint, honour it for document-supported providers the way the custom
   branch already does, so drag and paperclip agree. The provider's own document types
   and images stay accepted as now when nothing is configured.
2. Add msg: 'application/vnd.ms-outlook' to codeTypeMapping beside eml, and
   application/vnd.ms-outlook to applicationMimeTypes, so a Windows .msg with an
   empty File.type resolves to a real type and can be admitted by the default list
   or by configuration.
3. Extend the picker accept map so message/rfc822 and application/vnd.ms-outlook
   are selectable without switching the dialog to All Files.

Why it matters. Email is the container most professional users work from, and
an MCP tool that reads .eml/.msg on the server side is straightforward to build;
the client is currently the only thing in the way, and it is inconsistent between its
two entry points.

Measured on a deployment pinned to a late-July dev image: drag refused,
paperclip accepted, same file, same browser (Chrome and Edge on Windows). Happy to
provide a PR for 1 and 2 if the approach is acceptable.

More details

Both behaviours were confirmed against current main as well as the pinned build. Items 1 and 2 are small, self-contained changes; item 3 is a one-line addition to the accept map.

Which components are impacted by your request?

UI

Pictures

No response

Code of Conduct

• I agree to follow this project's Code of Conduct