feat(sds): persistent storage for history

[danisharora099]

Description

Currently, the message history used by SDS is stored only in memory. This causes SDS to lose all message history on every application restart, forcing a full recovery cycle each time. This leads to unnecessary network overhead, slower startup behavior, and inconsistent user experience between sessions.

Adding persistent storage for message history would allow SDS to resume from its previous state, improving performance and reliability across restarts.

---

User Story

• As a developer, I want SDS message history to persist across application restarts, so that recovery does not start from scratch each time.
• As an application user, I want message history to survive refreshes or restarts, so that the system feels consistent and responsive without repeated warm-up phases.
• As an integrator using non-browser environments, I want the ability to provide my own storage backend, so that I can still benefit from persistence when 1localStorage` isn't available.

---

Proposed Solution / Feature Design

Introduce persistent message history with a pluggable storage abstraction:

• Add a Storage interface used by MemLocalHistory and MessageChannel.
• Automatically use localStorage in browsers when available and serialization is supported.
• Allow developers to opt out of persistent storage.
• Allow custom storage providers for NodeJS and other non-browser environments.
• Maintain backwards compatibility — memory-only mode remains the fallback when persistence is not available.
• Add unit tests, e2e tests, and perform dogfooding to validate.

Behavior Summary

• Browser + localStorage available → persistent history enabled by default.
• Browser + persistence disabled → fallback to memory-only.
• NodeJS / non-browser → requires custom provider; otherwise uses memory-only.
• Message history survives reloads when persistent storage is active.

---

Notes

• Related to SDS startup performance and improving recovery behavior.
• Supports future extensible storage backends (e.g., IndexedDB, encrypted providers).
• Fully backwards compatible design.