What does this PR do?

Threads the optional ~/.hermes/default_profile_name renamed-root alias through the CLI/profile helpers so a renamed root profile (e.g. kinni) resolves to ~/.hermes consistently — hermes profile list, hermes profile show kinni, hermes -p kinni …, and the WebUI/profile API all see the alias as the root profile.

The fix routes the alias through normalize_profile_name, so every downstream helper (get_profile_dir, profile_exists, resolve_profile_env, delete_profile, set_active_profile, create_profile, rename_profile) auto-handles it without each having to be aware of the alias. list_profiles and get_active_profile_name surface the alias as the display name while keeping is_default=True. default continues to resolve to the root for back-compat.

The alias is silently ignored when:

• the file is missing/empty/unreadable
• the value fails _PROFILE_ID_RE validation
• the value equals default
• a real profiles/<alias>/ directory exists (named profile wins so it stays reachable)

The CLI surface for setting the alias — renaming the root profile, creating a ~/.local/bin/<alias> wrapper — is intentionally out of scope for this PR. The alias file is treated as input only; once any flow lands that writes it, this resolution layer already supports it.

Related Issue

Fixes #21105

Type of Change

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• Documentation update
• Code refactor / cleanup
• Performance improvement
• Test coverage improvement

Changes Made

• hermes_cli/profiles.py
  • new _get_root_alias() reader for ~/.hermes/default_profile_name with strict id validation, default-collision guard, and named-profile-wins fallback
  • normalize_profile_name resolves the alias to default so callers stay alias-agnostic
  • list_profiles displays the alias as the root row's name (still is_default=True)
  • get_active_profile_name returns the alias when HERMES_HOME resolves to root
• tests/hermes_cli/test_profiles.py
  • new TestRenamedRootAlias class (13 cases) covering all helpers, collision/invalid/empty cases, and unaffected behavior of ordinary named profiles

How to Test

1. Pin a renamed root alias and use the CLI:

   echo "kinni" > ~/.hermes/default_profile_name
   hermes profile list                  # root row labelled "kinni" (◆)
   hermes profile show kinni            # resolves to ~/.hermes
   hermes -p kinni config path          # ~/.hermes/config.yaml
   hermes -p default config path        # still works (back-compat)
   hermes profile delete kinni          # refused (root delete guard)

2. Confirm an ordinary named profile is unaffected:

   hermes profile create coder
   hermes -p coder config path          # ~/.hermes/profiles/coder/config.yaml

3. Confirm a real named profile shadows the alias:

   hermes profile create kinni
   hermes -p kinni config path          # named profile wins, alias dropped
   rm -r ~/.hermes/profiles/kinni

4. Run focused tests:

   pytest tests/hermes_cli/test_profiles.py -q

Code Checklist

• My code follows the Conventional Commits format (e.g. feat:, fix:, docs:)
• I have not opened a duplicate PR for this change
• My PR contains only changes related to this fix/feature
• All tests pass locally (pytest tests/ -q)
• I have added or updated tests for my changes
• I have tested on relevant platforms (macOS / Linux / WSL2 if applicable)

Documentation Checklist

• Updated README.md or docs/ if user-visible behavior changed
• Added/updated config keys in cli-config.yaml.example if any new YAML keys were introduced
• Updated CONTRIBUTING.md or AGENTS.md if architecture changed
• Cross-platform impact considered (macOS, Linux, WSL2)