fix(tui): read terminal.cwd from config.yaml in _completion_cwd()

[yeeyuny]

The TUI's _completion_cwd() function resolves the working directory for new sessions and completions, but its priority chain falls through to os.getcwd() without ever checking the profile's terminal.cwd setting in config.yaml. This means that regardless of what the user configured, the TUI always uses the directory from which hermes --tui was launched.

In contrast, the WebUI bypasses this by injecting a [Workspace::v1: ...] tag into every user message, overriding the cwd at the agent level.

Fix: insert a config.yaml terminal.cwd read into the _completion_cwd() priority chain, between TERMINAL_CWD and os.getcwd(). This makes the TUI respect the configured workspace automatically, while preserving all existing priorities (explicit user choice > session cwd > TERMINAL_CWD env > config > fallback).

Priority chain after this change:

1. params['cwd'] (explicit user/workspace choice from frontend)
2. session['cwd'] (existing session's cwd)
3. TERMINAL_CWD env var (worktree mode)
4. config.yaml terminal.cwd (profile-configured workspace) <-- NEW
5. os.getcwd() (final fallback)

What does this PR do?

Related Issue

Fixes #

Type of Change

• 🐛 Bug fix (non-breaking change that fixes an issue)
• ✨ New feature (non-breaking change that adds functionality)
• 🔒 Security fix
• 📝 Documentation update
• ✅ Tests (adding or improving test coverage)
• ♻️ Refactor (no behavior change)
• 🎯 New skill (bundled or hub)

Changes Made

How to Test

Checklist

Code

• I've read the Contributing Guide
• My commit messages follow Conventional Commits (fix(scope):, feat(scope):, etc.)
• I searched for existing PRs to make sure this isn't a duplicate
• My PR contains only changes related to this fix/feature (no unrelated commits)
• I've run pytest tests/ -q and all tests pass
• I've added tests for my changes (required for bug fixes, strongly encouraged for features)
• I've tested on my platform:

Documentation & Housekeeping

• I've updated relevant documentation (README, docs/, docstrings) — or N/A
• I've updated cli-config.yaml.example if I added/changed config keys — or N/A
• I've updated CONTRIBUTING.md or AGENTS.md if I changed architecture or workflows — or N/A
• I've considered cross-platform impact (Windows, macOS) per the compatibility guide — or N/A
• I've updated tool descriptions/schemas if I changed tool behavior — or N/A

For New Skills

• This skill is broadly useful to most users (if bundled) — see Contributing Guide
• SKILL.md follows the standard format (frontmatter, trigger conditions, steps, pitfalls)
• No external dependencies that aren't already available (prefer stdlib, curl, existing Hermes tools)
• I've tested the skill end-to-end: hermes --toolsets skills -q "Use the X skill to do Y"

Screenshots / Logs

[OutThisLife]

Closing in favor of #40892, which fixes this area correctly and is ready to merge.

This change reads _load_cfg(), i.e. the launch profile's config. In the desktop's app-global remote mode (the actual repro in #40334) every profile is served by one backend, so that resolves to the wrong profile and the switch bug stays. It also inserts the config read after TERMINAL_CWD, and the desktop always has TERMINAL_CWD set, so the new branch never fires there.

#40892 reads the bound profile's own config.yaml and places it before the stale env var, with placeholder/missing-dir handling and tests. The narrower case this PR gestures at (classic hermes --tui reading its own config when no env var is set) is a separate gap from #40334 and can be picked up on its own if it's worth it.

Appreciate the attempt here.