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

## 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.