What does this PR do?

Fixes the dashboard TUI startup hang reported in #31227 — the bundle produced only 141 bytes of ANSI reset sequences and then sat on a blank screen forever. Both `hermes --tui` and the dashboard `/chat` PTY were affected; no errors, no crash, the Node process and the spawned `python -m tui_gateway.entry` child both stayed alive.

Root cause. esbuild's lightweight `__esm` helper (line 14 of `dist/entry.js`) does NOT await nested async init:

```js
var __esm = (fn, res) => function __init() {
return fn && (res = (0, fn[__getOwnPropNames(fn)[0]])(fn = 0)), res;
};
```

So if any `async __esm` module participates in a circular import graph, the helper hands out a Promise that nobody completes — the top-level `await Promise.all([init_entry_exports().then(...)])` in `src/entry.tsx` waits forever.

The cycle came from `packages/hermes-ink/src/entry-exports.ts`:

```ts
export { default as TextInput, UncontrolledTextInput } from 'ink-text-input'
```

`ink-text-input` depends on the upstream `ink` npm package, whose graph then loops back through React + our in-tree `@hermes/ink` ink fork. The result was `init_entry_exports` emitted as `async … await init_build4()` (where `build4` = `node_modules/ink-text-input/build/index.js`), and the deadlock above.

Nothing in `ui-tui/` actually imports `TextInput` from `@hermes/ink` — the composer uses the in-tree `src/components/textInput.tsx` widget. The re-export was dead weight that dragged a whole second copy of the `ink` graph into the bundle.

Fix. Three small things wired together:

1. Drop the `from 'ink-text-input'` re-export in `packages/hermes-ink/src/entry-exports.ts` and `packages/hermes-ink/index.d.ts`. Callers that legitimately want the upstream widget can still import it via the dedicated `@hermes/ink/text-input` subpath, which sits outside `entry-exports` and so does not get inlined into consumers' bundles.
2. Update `scripts/build.mjs` to mention the second reason `@hermes/ink` is aliased to source (keep the upstream ink graph out of the bundle, not just esbuild's lazy-init quirk).
3. Add a vitest regression that builds `dist/entry.js` and pins two structural invariants — zero `async __esm` wrappers, and no upstream `ink` / `ink-text-input` modules in the bundle — so the next person who touches the re-export catches it locally before shipping.

After the fix:

• `dist/entry.js` shrinks 2.9MB → 2.4MB (~11.5k fewer bundled lines).
• Zero `async __esm` wrappers remain.
• `init_entry_exports` is now a synchronous `__esm` module.
• The bundle's top-level await chain resolves in ~30ms instead of hanging.

Related Issue

Fixes #31227

Type of Change

• 🐛 Bug fix (non-breaking change that fixes an issue)

Changes Made

• `ui-tui/packages/hermes-ink/src/entry-exports.ts` — drop the `'ink-text-input'` re-export; document why the cycle existed and where to import the widget instead.
• `ui-tui/packages/hermes-ink/index.d.ts` — drop the matching type re-exports so the type surface matches the runtime surface.
• `ui-tui/scripts/build.mjs` — expand the alias comment to cover both reasons `@hermes/ink` is aliased to source.
• `ui-tui/src/tests/bundleNoAsyncEsmDeadlock.test.ts` — 3 new tests (rebuilds bundle on demand, asserts no async __esm wrappers, asserts no upstream ink modules, asserts `init_entry_exports` is synchronous).

Backwards compatible: the only public-API surface affected is `TextInput` / `UncontrolledTextInput` exports from the package root. No existing `ui-tui/` code uses them; external consumers (if any) must switch to `import TextInput from '@hermes/ink/text-input'`, which already worked.

How to Test

```bash
cd ui-tui

Build

npm run build

expected: dist/entry.js is now 2.4MB (was 2.9MB on main)

New regression suite (3 tests, ~100ms)

npx vitest run src/tests/bundleNoAsyncEsmDeadlock.test.ts

expected: 3 passed

Full ui-tui regression excluding 5 pre-existing failures unrelated

to this PR (cursorDriftRegression / textInputFastEcho /

textInputWrap / virtualHeights / createSlashHandler — all reproduce

unchanged on upstream/main):

npx vitest run \
--exclude '/cursorDriftRegression.test.ts' \
--exclude '/textInputFastEcho.test.ts' \
--exclude '/textInputWrap.test.ts' \
--exclude '/virtualHeights.test.ts' \
--exclude '**/createSlashHandler.test.ts'

expected: 736 passed, 1 skipped

```

End-to-end behavior on the issue's exact repro:

```bash
HERMES_PYTHON=/path/to/venv/bin/python TERM=xterm-256color \
node --expose-gc ui-tui/dist/entry.js
```

• Before: ANSI reset bytes (141 of them), then permanent blank screen.
• After: TUI renders the chat layout normally.

Checklist

• Conventional Commits (`fix(tui):`, `docs(tui):`, `test(tui):`)
• 3 focused commits, single author (xxxigm)
• 3 new tests pass; 736 existing ui-tui tests pass; 28 unrelated pre-existing failures confirmed identical on upstream/main
• Tested on macOS 15.6 (darwin 24.6.0), Node 22.15.0
• No new config keys, no platform-specific code paths, no schema migration