Improve binary file detection logic

[shuuji3]

Describe the bug

Follow up of #1959

#1959 introduced binary file detection, but the current method relies on file extensions, which can lead to false positives.

As suggested in the PR, an alternative is to use file-type to detect file types by reading the magic number of the buffer.

Additional context

No response

Logs

[shuuji3]

When we request a file for the file viewer, we're fetching it from the jsdelivr CDN on the server side here:

npmx.dev/server/api/registry/file/[...pkg].get.ts

Line 54 in 3de681d

const url = `https://cdn.jsdelivr.net/npm/${packageName}@${version}/${filePath}`

I noticed that the response header already contains the correct content-type.

Example headers for a binary font file:

> http https://cdn.jsdelivr.net/npm/vitepress@1.6.4/dist/client/theme-default/fonts/inter-roman-greek-ext.woff2
HTTP/1.1 200 OK
Accept-Ranges: bytes
Age: 458324
CF-RAY: 9dac388a3f6feb91-NRT
Cache-Control: public, max-age=31536000, s-maxage=31536000, immutable
Connection: keep-alive
Content-Length: 16272
Content-Type: font/woff2
Date: Wed, 11 Mar 2026 17:18:52 GMT
NEL: {"success_fraction":0.01,"report_to":"cf-nel","max_age":604800}
Report-To: {"endpoints":[{"url":"https:\/\/a.nel.cloudflare.com\/report\/v4?s=tnq7Oe0nyxb%2Bxc1o5MQ5iY0PIJ2arRmpxIFJcP%2BZ2b%2FXqI582COSZqIPPOseqCDmYdRVMvGe3G%2BQOEiC8PndEtiwt4EMQG7dgdoZb85bobWp025RibspqUXxXxOeOkn5YUE3M5X2nPW57OMdIMM%3D"}],"group":"cf-nel","max_age":604800}
Server: cloudflare
access-control-allow-origin: *
access-control-expose-headers: *
alt-svc: h3=":443"; ma=86400
cf-cache-status: MISS
cross-origin-resource-policy: cross-origin
etag: W/"3f90-kIlNKWVlJK//2XgO3Mb26c1mOes"
strict-transport-security: max-age=31536000; includeSubDomains; preload
timing-allow-origin: *
vary: Accept-Encoding
x-cache: HIT, HIT
x-content-type-options: nosniff
x-jsd-version: 1.6.4
x-jsd-version-type: version
x-served-by: cache-fra-etou8220158-FRA, cache-tyo11968-TYO



+-----------------------------------------+
| NOTE: binary data not shown in terminal |
+-----------------------------------------+

• npmx URL: http://main.npmx.dev/package-code/vitepress/v/1.6.4/dist%2Fclient%2Ftheme-default%2Ffonts%2Finter-roman-greek-ext.woff2

It seems this content-type string is already beeing generated, probably using a method similar to file-type on a server application. I think we can simply pass this string through to the client to avoid reimplementing the same logic.

I'll try creating a PR with this approach later.