Fast discovery misses TypeScript NodeNext `.js` specifiers → silent WorkflowNotRegisteredError

Summary

A .ts file using TypeScript NodeNext-style specifiers — export * from './x.js' (what TS itself prescribes) — is invisible to workflow fast discovery. The build succeeds, the workflow/step never registers, and the first signal is a runtime WorkflowNotRegisteredError. esbuild resolves the same specifier fine during bundling, so only the discovery pass is affected.

Where

• packages/builders/src/fast-discovery.ts:754-757 — .js is in FAST_DISCOVERY_SOURCE_EXTENSION_SET, so the resolver does a bare fileExists on x.js and returns null without ever reaching the candidate-extension loop below.
• packages/builders/src/fast-discovery.ts:889-890 — relative specifiers go through that function only; there is no enhanced-resolve fallback for them.
• packages/builders/src/fast-discovery.ts:24-30 — the enhanced-resolve instance used for bare specifiers is constructed without extensionAlias, so deep package imports have the same hole.
• packages/builders/src/fast-discovery.ts:944-946 — unresolved edges are dropped with a bare return, no diagnostic, which is why the failure is silent.
• packages/builders/src/fast-discovery.test.ts uses .js specifiers (151, 207, 269, 765) but always against real .js files on disk, so this case is untested.

Suggested fix

Contained: in resolvePathLikeSpecifier, on a .js/.jsx/.mjs/.cjs miss, retry the .ts/.tsx/.mts/.cts candidates before returning null (i.e. implement the extensionAlias semantics), and consider emitting a diagnostic when a directive-bearing edge fails to resolve instead of dropping it silently.

Impact

This hits any TypeScript library author following NodeNext module resolution — exactly the audience of the publishing-libraries cookbook. Found while building the Mastra integration (@mastra/workflow), where it cost a debugging cycle.