fix(server): fall back to text/plain; charset=utf-8 when MIME type is unknown in artifact server

[nakatani-yo]

Motivation

On the Logs tab of a workflow node, clicking the "logs from the artifacts" link displays garbled text (mojibake) when the log contains non-ASCII characters such as multibyte (e.g. Japanese) text.

This happens because the artifact server runs inside a minimal container image (e.g. distroless) where the system MIME database (/etc/mime.types) is not available. In that environment, mime.TypeByExtension returns an empty string for extensions like .log, and the artifact is served with an empty Content-Type header. Without a proper Content-Type, the browser cannot determine the correct character encoding, resulting in garbled text.

Modifications

• In server/artifacts/artifact_server.go, added a fallback so that when mime.TypeByExtension returns an empty string, "text/plain; charset=utf-8" is used as the Content-Type instead.
• In server/artifacts/artifact_server_test.go, added a .log artifact (main-logs) to the test fixtures and a test case that verifies the Content-Type header is never empty for artifact responses.

Verification

• Added a unit test for .log artifacts that asserts Content-Type is non-empty.
• Verified manually that .log artifacts are now served with Content-Type: text/plain; charset=utf-8 in a distroless container environment.
• Confirmed that artifact contents containing multibyte characters are displayed correctly without garbled text (mojibake).

Documentation

This is a bug fix that does not change any user-facing API or configuration. No documentation update is needed.