d.ts files are getting ignored when entrypoint is a js file

[teidesu]

which leads to jsr resorting to trying to infer types trivially, and as a result - failure to use the library altogether.

mcve

deno.json

{
    "name": "@foo/bar",
    "version": "1.3.5",
    "exports": "./mod.js"
}

mod.js

const exports = {};

exports.ns = {};
(function(ns) {
    ns.bar = "egg";
})(exports.ns);

export const ns = exports.ns;

mod.d.ts

export declare namespace ns {
    const bar = "egg";
}

the above is similar to commonjs output from tsc for typescript namespaces

expected result

jsr uses d.ts files for typings and doesn't try to infer them on its own

actual result

jsr warns about "slow types" when publishing and advises to add d.ts files (which are already there):

warning[unsupported-javascript-entrypoint]: used a JavaScript module without type declarations as an entrypoint
 --> /path/to/mod.js
  = hint: add a type declaration (d.ts) for the JavaScript module, or rewrite it to TypeScript

  info: JavaScript files with no corresponding declaration require type inference to be type checked
  info: fast check avoids type inference, so JavaScript entrypoints should be avoided
  docs: https://jsr.io/go/slow-type-unsupported-javascript-entrypoint

btw, linked docs might be out of date? there's nothing mentioned about js entrypoints

additional context

due to this bug, export const ns from the mcve, whose type can't be trivially inferred, results being unusable at all:

// some other package
import { ns } from '@foo/bar'

console.log(ns.bar) // errors here, ns is not a namespace