tracking: scratchlist v2.1 - delete-session with summarize-and-migrate flow

Tracking issue (design TBD)

This is a follow-up to #893 (scratchlist v2.0). The hub-sync feature in v2.0 changes the storage layer; v2.1 builds an opt-in UX flow on top of it for "delete-session" specifically.

Problem

When the operator deletes a session that holds scratchlist entries, those entries are valuable parking-lot notes / future-work ideas - cascade-deleting them along with the session can lose work that was deliberately set aside for "later".

v2.0 mitigates the worst case with a confirmation copy showing the entry count, but doesn't offer a way to keep the scratchlist alive across the delete.

Operator framing

"If a session with scratchlist is attempted to be deleted, there should be an option given to the operator: 'you still have scratchlist items in this session. would you like to migrate a summary of this session to a new session and retain your scratchlist there? or just delete' - will need some workshopping on this one, the point is, there might be value for 'future work' here, that would be ideal not to 'lose'."

Proposed flow (v2.1, design TBD)

When the operator triggers delete on a session that has N >= 1 scratchlist entries:

1. Confirmation modal offers two paths:
   • Just delete - same as today.
   • Summarize and migrate - new path: hub spawns a one-shot summarisation of the session (model TBD), creates a new fresh session in the same workspace, copies the scratchlist entries over, and only THEN deletes the original session. The user lands in the new session with their parking-lot notes intact and a context paragraph explaining the prior session's work.

Open design questions

• Which model summarises? Cheapest-available (operator preference for cost-sensitive feature)? Same-as-session? User-pickable? Cancellable mid-flight?
• Cost / token budget. Long sessions can produce expensive summaries; need a hard ceiling and a "fall back to truncated message-list copy" path if exceeded.
• New session creation contract. What metadata does the new session inherit (workspace path, agent flavor, model)? Does it auto-spawn a runner or stay inactive?
• Failure modes. If summarisation fails, do we delete anyway, leave the session, or roll back to the modal?
• Migration of context. Does the summary go into the new session's first user message, into a metadata.summary field, or both?
• Scratchlist visual indication. When entries arrive in a fresh session via this path, should they have a "migrated from session X" tag for visibility?

Out of scope here

• Anything in v2.0 (#893): typed table, REST endpoints, SSE piggyback, silent localStorage migration, delete-confirmation copy.

Status

Tracking only. v2.0 ships first; this issue stays open for design + reviewer feedback. Implementation should not start until the model / cost / failure-mode questions above are resolved.

Start by reviewing the v2.0 work in #893 and the existing delete-session confirmation flow. Resolve the model, cost, session-creation, failure-mode, and migration questions with reviewer feedback; implementation should begin only after the design is settled.