Fixed issue with reset callback

[mgavrila]

Summary

• Fix reset callback flow in webview provider so that resetStateCallback is stored, invoked reliably on reset, and the provider can be re-initialized correctly.
• Improve observability and versioning by adding handshake/reset logging and bumping the package to 3.2.7-alpha.18.

Changes

• Store reset callback: Save resetStateCallback on the instance instead of wiring it directly through the constructor.
• Refactor reset listener: Introduce setupResetStateListener that:
  • Listens for resetStateResponse.
  • Immediately calls finalizeResetState() when the reset response is received.
  • Invokes the stored resetStateCallback after finalizing the reset.
  • Resets initialized to false so a new handshake can occur cleanly.
• Handshake flow:
  • Log initial handshake context (platform and initialized state).
  • After a successful finalizeHandshakeResponse, mark the provider as initialized and only then set up the reset listener when a resetStateCallback is present.
• Tooling & version:
  • Bump package.json version to 3.2.7-alpha.18.
  • Add publish-verdaccio script for local publishing.

Rationale

• Previously, the reset logic relied on passing the callback into the listener and used a fixed timeout before calling finalizeResetState, which could cause race conditions and unreliable reset behavior.
• The new flow centralizes the callback on the instance, removes arbitrary timing, and tightly couples reset completion with finalizeResetState, making the lifecycle easier to reason about and debug.

Testing

• Manual
  • Initialize the webview provider in a webview environment and complete the handshake.
  • Trigger a reset from the host environment and verify:
    • finalizeResetState is called once per reset.
    • The provided resetStateCallback is invoked exactly once.
    • initialized becomes false after reset and a subsequent handshake works correctly.
  • Check logs to ensure handshake and reset events are emitted as expected.