fix(coach): replay the newest messages, not the oldest 40 - #69

Bug

CoachViewModel.recentMessages builds the conversation history replayed to the model each turn. It fetched with:

sortBy: [SortDescriptor(\.createdAt, order: .forward)]   // OLDEST first
descriptor.fetchLimit = 40

fetchLimit is applied after the sort, so ascending + limit 40 returns the oldest 40 rows. .suffix(limit) then takes the last N of those oldest 40 → messages ~31–40.

Impact

• Conversation ≤ 40 messages: the fetch returns the whole thread, so .suffix genuinely is the newest N. Works — which is why it isn't caught in normal testing.
• Conversation > 40 messages: the fetch clamps to the oldest 40, so the replayed context is frozen at messages 31–40 forever — everything from message 41 on is never sent to the model. The coach silently "forgets" all recent turns, answers from stale mid-history, and re-sends the same block every turn (wasted tokens).

The chat continues the most recent thread by default (CoachView picks allMessages.last?.conversationId), so an engaged user's single conversation accumulates past 40 (~20 back-and-forth turns) and hits this. recentMessages is the only conversation history passed to the model (verified in CoachOrchestrator), so nothing else compensates.

Fix

Fetch the newest 40 (descending), restore chronological order, then .suffix(limit) as before:

sortBy: [SortDescriptor(\.createdAt, order: .reverse)]   // newest first
descriptor.fetchLimit = 40
let rows = Array(((try? context.fetch(descriptor)) ?? []).reversed())  // back to chronological

historyTurns is 4/10 so 40 remains an ample buffer after filtering the current turn + error bubbles. The ≤40-message case is unchanged. Latent bug (only bites long threads); builds clean.