Post-1.3: investigate slow session resume latency

[ebursztein]

Summary

Manual testing during the 1.3 release pass showed session resume taking several seconds before the shell became usable.

Observed

• Resuming an existing Capsem session felt noticeably slow.
• This was observed during manual end-user testing of the TUI / capsem shell path.

Expected

• Resume should be fast enough to feel interactive, or the UI/TUI should expose precise progress so the delay is understandable.

Notes

• Do not address in the 1.3 release lane unless it becomes release-blocking.
• Follow-up should measure resume stages with structured timing before optimizing.
• Check whether the delay is service route latency, profile readiness, disk/snapshot restore, shell attach, DB/status reads, or UI focus/render delay.

Acceptance Criteria

• Add timing around resume phases.
• Record benchmark numbers before and after any change.
• UI/TUI reports progress if unavoidable latency remains.
• No new fallback path or alternate session state model.