chore: surface underlying errors when session history fails to load

[luoxuanzao]

Summary

• The startup restore report only counted failed session history files and discarded the underlying readSDKSession error, so user feedback could never reveal the root cause. The history stage report now appends each failing session id with its error (e.g. Errors: <sessionId>: EPERM: operation not permitted, open '...').
• This change already proved its worth in the field: a diagnostic build with it let a user's console pinpoint an EPERM caused by endpoint security software blocking content access to ~/.qoder session files — previously invisible behind the bare "failed to load" count.
• Extended the existing (still unreleased) restore-diagnostics changelog entry to mention the underlying file error; the user-facing Notice is unchanged, details go to the developer console only.

Verification

• npm run typecheck
• npm run lint
• npm run test (3323 passed; new assertion covers the surfaced error detail)
• npm run build
• npm run release:check
• npm run audit:prod
• Tested affected qodercli behavior against a real CLI when applicable (a diagnostic build of this change was installed by an affected user; the console then showed the underlying EPERM error with the failing session path, confirming the enhancement works end to end)

Safety

• No credentials, private vault content, internal URLs, or personal paths are included
• User-visible changes are documented in CHANGELOG.md