(restore): follow a session's continuation instead of resuming the pre-fork transcript

[devsuitup]

Part B of #518 (part A, the live re-key from the CLI descriptor, waits for #477).

When a session is sent to the background, the CLI appends a continued-in record to the old transcript naming the new session id. Restore and the sidebar ignored it and resumed the pre-fork transcript.

Now:

• The session cache indexes continued-in records while scanning (bounded streaming fallback for stale indexes).
• Restore follows the chain (cycles and depth bounded). One terminal continuation: open it and rewrite the saved working-set entry. Several: nothing is spawned, the user picks. Cycle, missing target or scan limit: nothing is spawned, the user is told.
• A continuation that is a live background job goes through the existing attach path.
• A manual click on the old sidebar row offers the continuation instead of silently resuming the old transcript.
• Canary test pinning the undocumented continued-in field names.

Red-first: the first commit adds the tests alone (they fail on main); the second adds the fix.

[devsuitup]

Data point for the resolution rules, measured on the reporting machine:

• Of 7615734f's two continued-in targets, e7abbcdc has a transcript, but c1329340 has no .jsonl anywhere under ~/.claude/projects. Its job is done with no linkScanPath.
• A missing target should therefore be dropped from the candidates when another one exists, not turn the whole resolution into "unresolved". Otherwise this real case always asks instead of opening e7abbcdc.