fix(desktop): preserve project session profiles

[honki12345]

What does this PR do?

Fixes Hermes Desktop's Filters → Show → Profile option for session rows rendered inside Project grouping.

Project overview and drill-in rows come from the shared projects.tree projection. That projection dropped the persisted profile_name, so the renderer received no session.profile, normalized the row to default, and intentionally suppressed the profile glyph. The session itself was still correctly owned by the named profile; only its display metadata was missing.

This PR projects the existing profile identity into the response once, at the shared backend boundary. Named-profile project rows can therefore use the existing ProfileTag rendering path, while rows whose persisted profile is NULL retain the canonical default identity and existing default-profile UI behavior.

This is distinct from #86258 / #86259, which covers ordinary flat All Profiles recents and explicitly leaves scoped/project views unchanged.

Related Issue

Fixes #89731

Related: #72767, #86258

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

• tui_gateway/server.py
  • preserve the session row's owning profile in the shared project-tree projection
  • normalize a missing persisted profile to the canonical default identity
  • cover both projects.tree overview rows and projects.project_sessions drill-in rows through their shared projection
• tests/tui_gateway/test_projects_rpc.py
  • exercise the real temporary state.db → project RPC response path
  • verify named-profile and default-profile identities in both overview and drill-in payloads

How to Test

1. Select a named Desktop profile and create a session inside a project/worktree.
2. Set the session sidebar to Grouping → Project.
3. Enable Show → Profile.
4. Confirm the project session row shows the existing named-profile glyph and Profile: <name> accessible label.
5. Confirm default-profile rows retain their existing default-profile behavior.

Automated verification:

RED (before production change):
  scripts/run_tests.sh tests/tui_gateway/test_projects_rpc.py \
    -k project_session_rows_carry_profile_identity -q
  2 failed with KeyError: 'profile'

GREEN (after production change):
  same focused command
  2 passed

Related project RPC/tree suite:
  scripts/run_tests.sh tests/tui_gateway/test_projects_rpc.py \
    tests/tui_gateway/test_project_tree.py -q
  58 passed

Static checks:
  ruff check tui_gateway/server.py tests/tui_gateway/test_projects_rpc.py
  All checks passed

  python scripts/check-windows-footguns.py \
    tui_gateway/server.py tests/tui_gateway/test_projects_rpc.py
  No Windows footguns found

  git diff --check
  passed

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 — the focused and neighboring project RPC/tree suites passed; the full repository suite was not run locally
• I've added tests for my changes (required for bug fixes, strongly encouraged for features)
• I've tested on my platform: macOS 26.6.2, Python 3.11.15, Hermes 0.20.4

Documentation & Housekeeping

• I've updated relevant documentation (README, docs/, docstrings) — N/A; no documented command or configuration changed
• I've updated cli-config.yaml.example if I added/changed config keys — N/A; no config changes
• I've updated CONTRIBUTING.md or AGENTS.md if I changed architecture or workflows — N/A; existing response contract only
• I've considered cross-platform impact (Windows, macOS) per the compatibility guide; the change is data projection only and the Windows footgun scan passed
• I've updated tool descriptions/schemas if I changed tool behavior — N/A; no model tool changes

Screenshots / Logs

The original UI symptom is captured in #89731. The regression test records the exact response-shape failure (profile absent) and proves the repaired named/default profile contract through both project RPCs.