Adds support for multi display type messages

[BernardGatt]

Addresses: INAPP-14008

This PR adds support for multi-step display types and state saving between message step changes.

Note: gist-web-renderer/pull/32 Needs to be deployed first

---

Note

Enables multi-step display types with step change handling, persistent step/display state, and dynamic re-rendering without duplicate shows.

• Messages (core):
  • Handle changeMessageStep with displaySettings; apply changes via applyDisplaySettings and reload component without re-firing events or logging views.
  • Prevent duplicate shows per queueId; support saved step on initial load; differentiate first load vs display-change reloads.
  • Move message lookups/updates to utilities/message-utils; add display-type helpers and overlay position mapping.
• State Persistence:
  • Save/restore per-message step and display settings in local storage (30-day TTL); clear on dismiss/remove.
  • Exclude new .state keys from aggressive expiry cleanup.
• Renderer Communication:
  • Pass SDK capabilities (MultiStepDisplayTypes) and optional stepId to iframe on load.
• Queue Manager:
  • Restore saved state for persistent/show-always broadcasts before display; apply saved display settings.
• Components/UI:
  • loadEmbedComponent/loadOverlayComponent accept optional stepName; idempotent addPageElement.
• Settings:
  • Update dev GIST_VIEW_ENDPOINT to code.gist.build/renderer/0.6.0-preview13.
• Examples:
  • Add "Show HTML Multistep Message" demo and encoded multistep payload in examples/index.html.

^{Written by Cursor Bugbot for commit acf95ee. This will update automatically on new commits. Configure here.}

[cursor]

Bug: Redundant removeOverlayComponent call after hideOverlayComponent

In hideMessageVisually, when the message is an overlay, hideOverlayComponent() is called followed by removeOverlayComponent(). However, hideOverlayComponent() already calls removeOverlayComponent() at the end of its execution. This results in removeOverlayComponent() being called twice - the second call is redundant and indicates a logic error. While it won't crash due to null checking in removeOverlayComponent, it's wasteful and suggests the author may have misunderstood the existing function's behavior.