Salvages #28851 (@deas).

Problem

When HERMES_UID remaps the hermes user from the build-time UID 10000 to
another UID (typical use case: matching the host user's UID so bind-mounted
files are owned correctly), the TUI launcher's esbuild step fails:

$ docker run -e HERMES_UID=1000 -e HERMES_GID=1000 nousresearch/hermes-agent --tui

  ✘ [ERROR] Failed to write to output file:
     open /opt/hermes/ui-tui/dist/entry.js: permission denied
  TUI build failed.
  Error: Build failed with 1 error

This is because the Dockerfile's build-time chown -R hermes:hermes on
/opt/hermes/{.venv,ui-tui,node_modules} (line 154) wrote UID 10000, and
stage2-hook.sh only re-chowned .venv on UID remap — leaving the TUI
build trees still owned by the old UID. esbuild needs to rewrite
ui-tui/dist/entry.js on every launch where the source mtime is newer
than dist/ (or when HERMES_TUI_FORCE_BUILD=1 is set), and it runs
as the new hermes UID, which can no longer write to dist/.

Fix

Extend the stage2 re-chown to include the same set as the build-time
Dockerfile chown:

chown -R hermes:hermes \
    "$INSTALL_DIR/.venv" \
    "$INSTALL_DIR/ui-tui" \
    "$INSTALL_DIR/node_modules"

These are the runtime-writable trees under $INSTALL_DIR. Everything else
under /opt/hermes is read-only at runtime so keeping it root-owned is fine.

Sync rule documented in the comment so future Dockerfile chown changes
keep stage2 in step.

Validation

Wrote an isolated TUI UID-remap E2E harness that forces the build path
(HERMES_TUI_FORCE_BUILD=1) and runs docker run --tui with HERMES_UID=1000.

Baseline (origin/main, current behavior)

✗ Bug #28851 reproduced: esbuild EACCES on ui-tui/dist/
  ✘ [ERROR] Failed to write to output file: open /opt/hermes/ui-tui/dist/entry.js: permission denied
✗ TUI launcher reports build failed
✓ stage2 chown path triggered: [stage2] Fixing ownership of /opt/data (targeted) to hermes (1000)
✓ stage2 chown of $INSTALL_DIR build trees succeeded silently

Result: 3 pass, 2 fail — bug reproduces cleanly, container exits rc=1

Salvage (this PR)

✓ No esbuild EACCES on ui-tui/dist/ — fix in place
✓ TUI build did not fail
✓ ui-tui/dist/entry.js present in image after build
✓ Container reached TTY-check stage (expected non-interactive exit point)
✓ stage2 chown path triggered: [stage2] Fixing ownership of /opt/data (targeted) to hermes (1000)
✓ stage2 chown of $INSTALL_DIR build trees succeeded silently

Result: 6 pass, 0 fail — container exits rc=0

Regression checks

• Standard image smoke battery (--version, hermes_cli import, _tui_need_npm_install: False, --tui no-TTY exit, tools.lazy_deps import, gcc present): 6 pass, 0 fail
• Chown E2E from default entrypoint.sh recursively chown's to 10000:10000 - good thing I never ran it on my host root #19788 (host file ownership preserved under bind-mount): 7 pass, 0 fail

Authorship

Original change by @deas in #28851. Their branch targeted
docker/entrypoint.sh (a deprecated shim since the s6-overlay rework
moved the real cont-init logic into docker/stage2-hook.sh);
retargeted the fix accordingly. Preserved attribution via
Co-authored-by:.

Closes #28851.