Why: generated deliverables (e.g. meeting-minutes docx) had no reliable
download path — the content endpoint set no Content-Disposition, so the
filename only survived via the front-end <a download> attribute, and
contentTypeOf returned text/plain for any artifact whose MIME column was
empty, mangling office/pdf uploads.
Evidence: artifactContent now always sets Content-Disposition (inline by
default, attachment with ?download=1) with an RFC 5987 filename* for
non-ASCII names plus an ASCII fallback; contentTypeOf consults an
explicit office-format extension table then mime.TypeByExtension before
the kind fallbacks. New tests cover disposition on both modes, the
encoded Chinese filename, and the extension/mime precedence chain;
go test ./... green.
Impact: front-ends can link direct download URLs and browsers receive
correct file types for docx/xlsx/pptx/pdf/csv/md regardless of the
stored MIME value.
Refs: task feature/chat-order-artifact-files.
weichen
3a973e7ea8