[fabracht]

Summary

Fixes #48 — subscribeToConnectionStatus(cb) registered the callback but never fired it on connectivity transitions. The getter (connectionStatus) stayed correct; only the push channel was dead, so React/Vue connection indicators showed a permanently stale status.

Root cause was in the engine: @laboverwire/stitch-wasm 0.5.1 did not fan the MQTT client's connectivity events out to the wasm Store's status subscribers. Fixed upstream in stitch-rs #65 and shipped as @laboverwire/stitch-wasm 0.6.0. This release delivers it by raising the floor ^0.5.1 → ^0.6.0.

Changes

• package.json — version 0.6.3 → 0.6.4; @laboverwire/stitch-wasm floor ^0.5.1 → ^0.6.0.
• src/store.ts — folded in the adapter replay gap: deferrableSubscribe now pokes on the ready path too, not only the pre-init path. A subscriber attaching after initialize() resolved previously got no initial callback; it now gets a current read immediately, matching the pre-init path (connection indicators reflect live status on mount).
• CHANGELOG.md — ## 0.6.4.
• tests/integration/connection-status.test.ts — 2 regression tests: initial emit on subscribe-after-ready, and a real connecting → disconnected transition delivered to the subscriber (the scenario that produced [] on 0.5.1).

Compatibility

The 0.5 → 0.6 engine step is additive to the Store surface this adapter consumes — two new compare-and-set methods (updateIf, deleteIf) the wrapper does not expose — with no removed or changed signatures. subscribeToConnectionStatus, connectionStatus, and createStore keep their exact shapes. No @laboverwire/stitch type or signature changes.

Verification (on real stitch-wasm 0.6.0)

• npm run check — type-check + lint + format + 38/38 browser tests (was 36; +2 new).
• npm run build clean.
• Lockfile diff surgical: only stitch-wasm 0.5.1 → 0.6.0 resolution, 0 @esbuild removals.

Closes #48.