fix scope-load/clear subscribe notifications (0.3.1 / 0.2.1)

[fabracht]

Fixes subscribeToEntity/subscribeToScope never firing on scope load/clear — the gap surfaced while porting the TS @laboverwire/stitch package to consume stitch-wasm (7 integration tests failed on this).

Fix

• store.rs (spawn_filtered_forwarder): handle ScopeLoaded/ScopeCleared instead of dropping them. For a subscriber whose entity is affected and whose scope filter matches, synthesize a null-data MutationEvent (origin Load/Clear) and forward it through the same accept/send path. So subscribeToScope fires cb() and subscribeToEntity fires (null, op) — the existing "re-read everything" cue. The Load/Clear origin also satisfies the persistence-mode accept filter.
• memory_store.rs (create): root create resolves its mutation scope_id via resolve_scope (root's own id), matching update/delete, so all three land under the same (scope_id, entity) key.

Tests

• Native subscribe_fires_on_scope_load_and_clear (times out before the fix).
• Browser subscribe_to_scope_fires_on_replace_scope_in_browser (mirrors the JS repro with persistence + replaceScope).

Release (bundled)

• stitch-sync 0.3.0 → 0.3.1, stitch-wasm 0.2.0 → 0.2.1 (dep updated), CHANGELOG entries for both. Patch bump — backward-compatible bug fix.

Verified: fmt/clippy both targets clean; native suites + broker/last-will green (no regressions); browser suite 21/21.

Tagging v0.3.1 after merge publishes both crates; npm stays manual (cargo make wasm-publish).