fix(desktop): stop retry/restore from truncating unpersisted failed turns

[JoaoMarcos44]

What does this PR do?

planReload (Retry) and planRestore (restore-to-message) computed a truncate ordinal unconditionally, even when the target turn's user message never reached the gateway (e.g. a request that died on an HTTP 429 before the turn was ever persisted). With no durable row id to anchor it, that request travels the legacy truncate_before_user_ordinal-only path, whose address space can drift from the gateway's after compaction/rebuilds — silently truncating the wrong turn.

Root cause

planEdit already guards this exact case with an isFailedTurn check (nextMessage?.role === 'assistant' && Boolean(nextMessage.error)) that resubmits plainly instead of requesting a truncation it can't safely address. planReload and planRestore are the two remaining ReloadPlan/RestorePlan builders that never got the same guard — this PR applies the identical, already-proven pattern to both.

Why a client-side fix, not just a gateway guard

#86605 addresses this from the gateway side: it fails closed (4004) whenever an ordinal-only truncation request targets a session that has any durable row ids in its history. That's a reasonable defense-in-depth net, but on its own it does not fix the actual bug — it just turns "silently truncates the wrong turn" into "the Retry button now hard-fails" for the exact retry-after-failure scenario the issue describes, since planReload/planRestore (pre-fix) genuinely do emit ordinal-only requests for unpersisted failed turns. That PR's own "ruled out" section states failed-turn planning "does not request truncation," which this repro shows is not accurate for planReload/planRestore prior to this fix.

This PR fixes the producer instead: the client simply stops asking the gateway to truncate by position when it has no durable identity to offer, exactly like planEdit already does. Retry and Restore keep working after a failed turn; they resubmit plainly with no truncation at all, matching the safe, already-shipped behavior of Edit. This is complementary to (not a duplicate of) any gateway-side hardening.

Changes Made

• apps/desktop/src/app/session/hooks/use-prompt-actions/rewind.ts
  • ReloadPlan.truncateOrdinal and RestorePlan.truncateOrdinal widened to number | undefined.
  • planReload and planRestore now null out truncateOrdinal / truncateMessageId / truncateRowId when the target turn's assistant response carries an error (the same isFailedTurn heuristic planEdit already uses).
• apps/desktop/src/app/session/hooks/use-prompt-actions/rewind.test.ts
  • New planReload and planRestore describe blocks covering the normal (persisted) case and the failed-turn case.

Related Issue

Fixes #86573

Test plan

• Added unit tests for planReload and planRestore covering both the persisted and failed-turn cases (rewind.test.ts).
• Manual: trigger a 429/failed turn on Desktop, click Retry, verify no truncation is requested and the turn resubmits cleanly.

Diagram

%%{init: {'theme': 'dark', 'themeVariables': { 'primaryColor': '#00f0ff', 'mainBkg': '#0a0a16', 'primaryTextColor': '#ffffff', 'primaryBorderColor': '#ff007f', 'lineColor': '#00f0ff'}}}%%
graph TD
    A[User clicks Retry / Restore] --> B{Target turn's assistant reply has error?}
    B -->|No - persisted turn| C[Attach durable row id + ordinal]
    B -->|Yes - never reached gateway| D[isFailedTurn guard]
    D --> E[Send plain resubmit - no truncation params]
    C --> F[prompt.submit with truncate_before_row_id]
    E --> G[Gateway: no truncation requested - safe]
    F --> H[Gateway: durable target - safe]

Loading