CommonJS require export targets point to ESM .js files

### Describe the bug

The @base-org/account package declares "type": "module" but several package.json exports still define "require" targets that point to .js files such as ./dist/index.js and ./dist/index.node.js. Because the package is ESM via "type": "module", these .js files are treated as ES modules by Node.js. As a result, CommonJS consumers using require() may hit ERR_REQUIRE_ESM even though the package exports explicitly advertise require support.

### Steps

1. Open packages/account-sdk/package.json
2. Notice that the package declares:

"type": "module"

3. In the same package.json, check the exports field
4. Notice that several entries define "require" targets pointing to .js files, for example:

"require": "./dist/index.js"
"require": "./dist/index.node.js"
"require": "./dist/interface/payment/index.js"
"require": "./dist/interface/payment/index.node.js"

5. Open packages/account-sdk/tsconfig.base.json
6. Notice that the package is compiled with:

"module": "ESNext"

7. Try to consume the package from a CommonJS file:

```js
const { createBaseAccountSDK } = require('@base-org/account');
```

or:

```js
const { base } = require('@base-org/account/node');
```

8. Node resolves the "require" condition to a .js file inside a package marked as "type": "module"
9. This can fail because the resolved file is still treated as ESM

### Expected behavior

If the package exposes "require" conditions, those targets should point to actual CommonJS-compatible files.

Expected behavior should be one of:

1. Provide real CommonJS builds, for example .cjs files, and point "require" to those files
2. Remove the "require" conditions and make the package ESM-only
3. Use a dual-package setup where "import" resolves to ESM and "require" resolves to CJS

### Version

2.5.6 / latest master

### Additional info

Suggested fix option 1: produce CommonJS build outputs.

Example package export shape:

```json
{
"type": "module",
"exports": {
".": {
"types": "./dist/index.d.ts",
"import": "./dist/index.js",
"require": "./dist/index.cjs"
},
"./node": {
"types": "./dist/index.node.d.ts",
"import": "./dist/index.node.js",
"require": "./dist/index.node.cjs"
}
}
}
```

Suggested fix option 2: remove the "require" conditions if CommonJS is not supported.

Example:

```json
{
"exports": {
".": {
"types": "./dist/index.d.ts",
"import": "./dist/index.js"
},
"./node": {
"types": "./dist/index.node.d.ts",
"import": "./dist/index.node.js"
}
}
}
```

Why this matters:

The current package.json suggests CommonJS support, but the target files are still ESM because of "type": "module". That can break Node/CommonJS users and create confusing runtime errors.

### Desktop

_No response_

### Smartphone

_No response_

Start with packages/account-sdk/package.json and packages/account-sdk/tsconfig.base.json, then reproduce the require() examples from a CommonJS entry point. Trace the package exports to the generated files and determine whether the package should provide CommonJS targets or remain ESM-only. Done means the exports accurately reflect the supported module format and the corresponding consumer check no longer fails.

Written by the indexing model from the issue text.