test: lock browser package export contract

[kantorcodes]

Summary

Adds a regression test that locks the browser-facing package contract exposed by @hashgraphonline/standards-sdk.

This is the source-side follow-up to the downstream alias churn: the SDK itself should keep exporting and building the browser entrypoints that consumers rely on instead of encouraging package aliases as a workaround.

What Changed

• adds __tests__/package-exports.test.ts
• asserts the root browser export still points at browser-root
• asserts ./browser stays exported
• asserts the browser build scripts remain part of build and prepublishOnly
• asserts src/browser-root.ts remains present

Verification

• pnpm exec jest --config jest.config.json --runInBand --coverage=false __tests__/browser-entry.test.ts __tests__/package-exports.test.ts
• pnpm run lint
• pnpm run typecheck
• pnpm run build

Scope

This PR intentionally avoids unrelated dirty worktree changes in the local checkout and only carries the regression coverage for the package contract.

[kilo-code-bot]

Code Review Summary

Status: No Issues Found | Recommendation: Merge

Overview

Severity	Count
CRITICAL	0
WARNING	0
SUGGESTION	0

Verification

The test file __tests__/package-exports.test.ts has been verified against the current package.json:

• Line 41: browser field matches package.json line 65 ✓
• Lines 43-49: Root export browser field matches lines 68-72 ✓
• Lines 51-57: ./browser export matches lines 78-83 ✓
• Lines 63-67: Build scripts (build:browser-root, build:browser) match lines 88-89 ✓
• Line 65-67: build script contains both browser builds - matches line 92 ✓
• Lines 68-70: prepublishOnly contains both browser builds - matches line 97 ✓
• Line 76: src/browser-root.ts exists ✓

The test correctly validates all the browser export contracts mentioned in the PR description.

Files Reviewed (1 file)

• __tests__/package-exports.test.ts - No issues

---

_{Reviewed by minimax-m2.5-20260211 · 169,725 tokens}

[gemini-code-assist]

Code Review

This pull request adds a new test suite to validate the published package contract, including browser entrypoints and build scripts. The review feedback suggests replacing process.cwd() with relative path resolution to ensure the tests are robust across different execution environments, particularly in monorepo setups.

[gemini-code-assist]

Using process.cwd() to resolve the path to package.json can be unreliable in monorepo environments where the current working directory might be the repository root instead of the package root. This can lead to tests reading the wrong configuration or failing to find the file. It is more robust to resolve paths relative to the test file's location.

[gemini-code-assist]

Similar to the package.json resolution, using process.cwd() to find source files makes the test dependent on the directory from which the test runner is executed. Using a relative path from the test file would be more robust and consistent across different execution environments.