`@fedify/init` crashes on JSR and Deno because it assumes `import.meta.dirname` is available

[dahlia]

Summary

fedify init fails when @fedify/cli or @fedify/init is executed through the JSR/Deno distribution, because @fedify/init assumes import.meta.dirname is always defined.

Steps to reproduce

1. Run deno run -A jsr:@fedify/cli@2.0.5 init --help
2. Observe that the command crashes before showing help or running the initializer

Actual behavior

The command fails with the following error:

error: Uncaught (in promise) TypeError: The "path" argument must be of type string. Received undefined
export const PACKAGES_PATH = joinPath(
                             ^
    at assertPath (ext:deno_node/path/_util.ts:10:11)
    at join (ext:deno_node/path/_posix.ts:95:5)
    at https://jsr.io/@fedify/init/2.0.5/src/action/const.ts:3:30

Expected behavior

The JSR/Deno distribution of fedify init should work without assuming a local checkout layout or Node-style import.meta.dirname support.

Root cause

@fedify/init computes PACKAGES_PATH at module initialization time using import.meta.dirname! in packages/init/src/action/const.ts. In the JSR/remote-module execution path, import.meta.dirname is undefined, so the module crashes as soon as it is loaded.

This is not only a test-mode problem. The package also uses import.meta.dirname! for template loading in packages/init/src/lib.ts, so the current implementation relies on filesystem-relative assets in ways that are not safe for the published JSR package.

Suggested fix

Make @fedify/init safe for published JSR execution:

• Do not compute repository-relative paths at module top level
• Avoid assuming import.meta.dirname exists
• Gate local-workspace path logic behind test-only code paths
• Bundle or embed template assets in a way that works in JSR/published environments instead of reading sibling files from disk

Notes

This issue is specifically about the JSR/Deno crash. The prompt-flow/documentation mismatch reported in #623 should be tracked separately.