#5935: fix(slack): persist thread starter body across thread messages

## Problem When using Slack threads with `thread.inheritParent: true`, the thread starter message (the parent message that started the thread) was only injected into the LLM context on the **first message** in the thread (`isNewSession === true`). After that first message, subsequent thread replies lost the thread starter context entirely, meaning the LLM had no visibility into what the thread was about. ## Root Cause In `get-reply-run.ts`: ```typescript const threadStarterNote = isNewSession && threadStarterBody // <-- only on first message! ? \`[Thread starter - for context]\n\${threadStarterBody}\` : undefined; ``` ## Solution 1. Add `threadStarterBody?: string` field to `SessionEntry` type 2. Persist `ctx.ThreadStarterBody` to `sessionEntry.threadStarterBody` when a new thread session is created 3. On subsequent messages, use the persisted `sessionEntry.threadStarterBody` (falling back to `ctx.ThreadStarterBody` for the first message) 4. Remove the `isNewSession &&` condition so thread starter is always included ## Testing - Build passes (`pnpm build`) - Type check passes (`tsc --noEmit`) - Changes are minimal and focused ## Files Changed - `src/config/sessions/types.ts` - Add `threadStarterBody` field to SessionEntry - `src/auto-reply/reply/session.ts` - Persist thread starter body on session init - `src/auto-reply/reply/get-reply-run.ts` - Use persisted thread starter body <!-- greptile_comment --> <h2>Greptile Overview</h2> <h3>Greptile Summary</h3> This PR persists Slack thread starter message text (`threadStarterBody`) into the per-session store and injects it into the agent prompt on every thread reply, so later messages in a thread keep the original context. Changes span the session entry schema (`src/config/sessions/types.ts`), session initialization (`src/auto-reply/reply/session.ts`) to persist the value, and reply execution (`src/auto-reply/reply/get-reply-run.ts`) to prefer the persisted value over transient context fields. <h3>Confidence Score: 4/5</h3> - This PR is likely safe to merge, with one ordering issue that can prevent the persisted thread starter from being injected in some runs. - The change is small and type-safe (adds an optional field and wires it through session init and prompt building). The main concern is that `threadStarterNote` is computed before `ensureSkillSnapshot` potentially replaces `sessionEntry`, which can drop the intended persisted context in scenarios where the refreshed entry is the only source of the thread starter body. - src/auto-reply/reply/get-reply-run.ts <!-- greptile_other_comments_section --> _{(2/5) Greptile learns from your feedback when you react with thumbs up/down!} **Context used:** - Context from `dashboard` - CLAUDE.md ([source](https://app.greptile.com/review/custom-context?memory=fd949e91-5c3a-4ab5-90a1-cbe184fd6ce8)) - Context from `dashboard` - AGENTS.md ([source](https://app.greptile.com/review/custom-context?memory=0d0c8278-ef8e-4d6c-ab21-f5527e322f13)) <!-- /greptile_comment -->