ESM build cannot be imported by Node: internal specifiers have no file extensions

### Description

`@hashgraph/asset-tokenization-sdk@8.0.0` cannot be loaded by Node. The ESM build imports
its own modules without file extensions, which Node's ESM resolver rejects.

**Expected:** `await import("@hashgraph/asset-tokenization-sdk")` resolves, as it does for
any package shipping an `esm` build.

**Actual:** it throws `ERR_MODULE_NOT_FOUND` on the package's own first internal import.

Bundlers still resolve it, because bundler resolution probes for extensions. So the
package works in Vite and webpack, and fails the moment it is loaded by the runtime its
own directory name claims to target.

Windows 11, Node.js 22.23.2

### Steps to reproduce

1. `npm i @hashgraph/asset-tokenization-sdk`
2. Import it from Node with no bundler in the path:

```sh
node --input-type=module -e "await import('@hashgraph/asset-tokenization-sdk')"
```

3. It fails:

```
Error [ERR_MODULE_NOT_FOUND]: Cannot find module
.../build/esm/src/port/in/index
imported from .../build/esm/src/index.js
```

The file exists — as `index.js`. ESM requires fully specified specifiers, and the emitted
build writes `./port/in/index`.

### Additional context

### Impact

None of this is reachable through the SDK without a bundler in the path:

- issuing or managing securities from a backend
- a keeper or scheduler process
- integration tests in Node
- inspecting the package's exports, which is the first thing anyone does when reaching for
an unfamiliar library

`@hashgraph/asset-tokenization-contracts` with typechain and an `ethers.Wallet` is a
working alternative for the first two, and #1397 documents someone doing exactly that. But
that is a different and lower-level API — what becomes unavailable is the request and port
surface this package exists to provide.

### Relationship to #1397

#1397 asks for a headless signing path, on the grounds that deploy scripts, indexers,
keeper bots and CI jobs have no way to use the SDK today.

The two are independent, and this one comes first: adding `SupportedWallets.PRIVATE_KEY`
would not make the package importable by Node. Backend usage needs both fixed, and this
one is a compiler option.

### Suggested fix

Emit `.js` extensions in the ESM output. With TypeScript that is `"module": "node16"` or
`"nodenext"`, which makes the compiler enforce specifiers at build time rather than
leaving them to fail at import time.

One line in CI would keep it fixed:

```sh
node --input-type=module -e "await import('@hashgraph/asset-tokenization-sdk')"
```

### Workaround

Load the package through something with bundler-style resolution — `tsx`, `vite-node`, or
a bundle step. There is no way to make plain `node` import it.

### Hedera network

other

### Version

@hashgraph/asset-tokenization-sdk 8.0.0

### Operating system

Windows

Inspect the TypeScript configuration and the generated build/esm/src/index.js, where the extensionless internal import is reported. First run the provided plain-Node import command, then rebuild and verify that `await import('@hashgraph/asset-tokenization-sdk')` succeeds without a bundler; add the suggested CI check if the build workflow is in scope.

Written by the indexing model from the issue text.