Audit TS module/target config and fix extensionless relative imports across packages

[Reversean]

Problem

Several relative imports in packages/sdk (and likely elsewhere in the
monorepo) omit the .js extension or import a directory instead of its
index.js file, e.g. from '../../entities' instead of
from '../../entities/index.js'.

Since @editorjs/sdk's package.json has "type": "module", Node's ESM
resolver is strict about this: a value import through a bare directory
specifier throws ERR_UNSUPPORTED_DIR_IMPORT, and a missing extension on a
file specifier throws ERR_MODULE_NOT_FOUND. Type-only (import type)
specifiers with the same issue don't break at runtime (TS strips them
entirely), but they do break .d.ts resolution for consumers using
moduleResolution: node16/nodenext.

This doesn't surface as a failure anywhere in the repo today, since the only
consumers are Vite (packages/playground) and ts-jest (test suites) — both
resolve directories/extensions leniently, unlike raw Node ESM. But
@editorjs/sdk is published to npm, so any external consumer running it
under plain Node would hit this.

Known instances

• packages/sdk/src/entities/InlineTool.ts
• packages/sdk/src/entities/BlockTool.ts
• packages/sdk/src/entities/BlockTune.ts
• packages/sdk/src/entities/EditorjsPlugin.ts
• packages/sdk/src/entities/EditorjsAdapterPlugin.ts
• packages/sdk/src/entities/BlockToolAdapter.ts
• packages/sdk/src/entities/EventBus/events/core/ToolLoadedCoreEvent.ts
• packages/sdk/src/entities/EventBus/events/core/SelectionChangedCoreEvent.ts

Similar patterns likely exist elsewhere in the monorepo, outside packages/sdk.

Proposed scope

• Audit module/moduleResolution/target in each package's tsconfig to
  match how it's actually consumed (bundler vs. Node ESM).
• Fix extensionless/directory relative imports repo-wide.
• Consider an ESLint rule (e.g. import/extensions) to prevent regressions
  going forward.