fix(desktop): render pinned search sessions

[ferminquant]

Summary

• Render pinned Desktop sessions that were pinned from search even when they are absent from the normal loaded sidebar session list.
• Hydrate any persisted pinned session IDs that cannot be resolved from loaded sessions or cached search-result metadata via GET /api/sessions/{id} after app reload.
• Add shared helpers for resolving pins and detecting missing pinned IDs, with focused regression coverage for reload hydration candidates and _lineage_root_id behavior.

Root Cause

Pinned session IDs were persisted correctly, but the Desktop sidebar rendered pinned rows by resolving those IDs only against the current loaded $sessions list. Search can return sessions that are not in that loaded list, so pinning a search-only result stored the pin but left the pinned section with no session record to render. The previous component-local search-result cache fixed the immediate render, but did not survive a full app reload.

Fix

• Keep using loaded sessions first so fresh sidebar data wins over fallback metadata.
• Keep the search-result fallback so a newly pinned search-only row appears immediately.
• On reload, detect persisted pinned IDs that are missing from both sources and fetch their full session metadata from GET /api/sessions/{id}.
• Match the Desktop session-detail endpoint shape, which returns the raw SessionInfo object.
• Avoid retry loops by remembering failed hydration lookups for the current component lifetime.

Test Plan

• npm run build
• npm run test:ui -- src/store/session.test.ts
• npm run type-check
• npx eslint src/store/session.ts src/store/session.test.ts src/hermes.ts src/app/chat/sidebar/index.tsx
• git diff --check

Verification Notes

• The regression tests now cover:

  • search-only pinned sessions resolving from fallback metadata;
  • loaded sessions taking precedence over stale fallback metadata;
  • _lineage_root_id fallback resolution;
  • missing pinned IDs being identified for reload hydration;
  • lineage-root pins not being hydrated when a loaded continuation tip already resolves them.

• Verified against the actual affected local session from [Bug]: Desktop pinned search result does not appear when session is hidden from normal list #37582:

  • 20260602_133018_d1c043 / desktop ui bug exists in the local session DB;
  • it is excluded from the normal list_sessions_rich(..., include_children=False) sidebar list;
  • it appears when children are included;
  • the same bug* FTS query pattern used by /api/sessions/search?q=bug returns that session;
  • GET /api/sessions/20260602_133018_d1c043-equivalent DB lookup returns the raw session record;
  • a temporary focused Vitest check confirmed the new reload path identifies that exact pinned ID as missing, calls /api/sessions/20260602_133018_d1c043, and then resolves it into the pinned session list.

• Headless Desktop UI repro was run for real on this PR branch/build:

  • Built Desktop with npm run build, producing install stamp 8d134f7502a0 (fix/desktop-pinned-search-session).
  • Launched the built Electron/Desktop app against the real local Hermes state DB using Electron headless/Ozone mode and CDP.
  • In the headless live Desktop UI, searched for bug and shift-click pinned the search result for the affected session (20260602_133018_d1c043).
  • Confirmed Desktop persisted localStorage['hermes.desktop.pinnedSessions'] as ["20260602_133018_d1c043"].
  • Reloaded the Desktop app.
  • After reload with an empty search field, the sidebar rendered:
    • PINNED
    • desktop ui bug
    • SESSIONS 4/12
  • This confirms the pinned row survives reload even though the session is absent from the normal loaded session list.

• Negative control on current origin/main without this PR fix was also run with the same real local state DB:

  • Built Desktop from origin/main at b34ee80741db2fdf188dcdc5c5caa78ee72642ff with a clean install stamp (dirty: false).
  • Launched that built Electron/Desktop app headlessly with CDP against the same local Hermes DB.
  • Persisted the same pinned ID (["20260602_133018_d1c043"]) and reloaded the Desktop app.
  • After reload, localStorage still contained the pinned ID, but the sidebar rendered the empty pinned-state copy (Shift click to pin a chat) and did not render desktop ui bug.
  • This reproduces the release/main failure mode and distinguishes it from the fixed PR build, where the same pinned ID renders as desktop ui bug after reload.

• Portable fresh-fixture negative control was also run on unpatched origin/main so the repro does not depend on the reporter's private local DB:

  • Inserted a new parent session repro_parent_20260602_newpin and child session repro_child_20260602_newpin titled new pinned child repro into a backed-up local state.db test run.
  • Confirmed GET /api/sessions/repro_child_20260602_newpin returned the raw child session record with parent_session_id = repro_parent_20260602_newpin and message_count = 1.
  • Confirmed the normal Desktop sidebar list (/api/sessions?limit=50&offset=0&min_messages=1&archived=exclude&order=recent) did not include the child session.
  • Launched the unpatched Desktop build from origin/main at b34ee8074 headlessly with CDP, persisted localStorage['hermes.desktop.pinnedSessions'] as ["repro_child_20260602_newpin"], and reloaded.
  • After reload, localStorage still contained the new pinned ID, but the sidebar rendered PINNED with Shift click to pin a chat and did not render new pinned child repro.
  • Removed the temporary DB fixture rows and restored the previous pinned localStorage after the repro.

Security / Privacy Impact

• No backend/API changes.
• No credentials, tokens, chat IDs, message content, or database files are added. Local session IDs/titles appear only as non-secret verification handles in the PR evidence.
• No new dependencies.

Scope Boundaries

• Narrowly fixes rendering for sessions pinned from search results that are not present in the normal loaded session list, including after app reload when the session can be hydrated from the existing session API.
• Preserves existing _lineage_root_id durable pin behavior.
• Does not address the separate unexpected parent_session_id behavior described in the issue context.
• Does not rewrite sidebar loading, search APIs, or session persistence.

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; PR fix(desktop): triage batch of GUI quality-of-life fixes #37536 is adjacent coordination, not a duplicate of this pinned-search fix.
• My PR contains only changes related to this fix.
• Relevant checks pass for this Desktop TypeScript change: npm run build, npm run test:ui -- src/store/session.test.ts, npm run type-check, targeted npx eslint, and git diff --check.
• I've added tests for my changes.
• I've tested on my platform: WSL2 with built Electron/Desktop in headless/Ozone/CDP mode.

Documentation & Housekeeping

• Documentation update: N/A — no user-facing behavior, config, or CLI docs changed.
• cli-config.yaml.example update: N/A — no config keys changed.
• CONTRIBUTING.md / AGENTS.md update: N/A — no architecture or workflow changed.
• Cross-platform impact considered: renderer/session metadata change only; no OS-specific file/process/terminal behavior changed.
• Tool descriptions/schemas update: N/A — no tool behavior changed.

For New Skills

• N/A — this PR does not add or modify a skill.

Screenshots / Logs

• Headless Desktop UI verification and negative-control logs are summarized above.

Fixes #37582

[Morad37]

One thing I would change before merge: this only caches the search result in component state. It fixes the immediate pin action, but the pin can disappear again after a full app reload if the session is still outside the normal loaded page.

The API already has GET /api/sessions/{id}; hydrating missing pinned ids from that endpoint would make the fix durable without widening the sidebar list.

[teknium1]

Thanks for isolating the persisted-search-pin failure. The underlying issue is still present on current main: apps/desktop/src/app/chat/sidebar/index.tsx:363-377 resolves persisted IDs only from loaded sidebar rows, while search pinning at :1147 persists only an ID.

Problems

• The new lookup at apps/desktop/src/app/chat/sidebar/index.tsx:409 calls getSession(pinId) without a profile. Current main supports profile-scoped rows (apps/desktop/src/types/hermes.ts:358-361) and its existing uncached-ID resolver probes the active and other profiles (apps/desktop/src/app/session/hooks/use-session-actions/utils.ts:215-248). A pin from another profile would remain unresolved after reload.
• The replacement resolver at apps/desktop/src/app/chat/sidebar/index.tsx:442 receives only sessions. Current main intentionally includes cronSessions in the pinned index (apps/desktop/src/app/chat/sidebar/index.tsx:349-361), so this would remove pinned cron rows.

Suggested changes

• Rework the hydration around the current profile-aware resolution path and preserve the resolved row's profile.
• Keep cron pin resolution and cover it with a regression test in addition to the search-only reload case.

This is an automated hermes-sweeper review.

[teknium1]

Current main supports profile-scoped sessions, but this only queries the active backend. Please use the current cross-profile stored-session resolution/probing behavior so persisted pins from another profile can hydrate after reload.

[teknium1]

This replaces the current resolver, which deliberately indexes cronSessions as well as recents for pinned rows. Passing only sessions would regress pinned cron-session rendering; preserve that source in the salvaged resolver.

[OutThisLife]

Superseded by #74234, which makes pins server-owned so they survive paging and sync between apps. Your work is carried in it and you're credited as a co-author — thank you.