fix(web): wire up the full version-vector catch-up path (#57, #59)

[pvg13]

Closes #57 and #58 issue followup #59.

The fix lands in three commits, in the order the bugs surface:

1. fix(web): trigger version-vector catch-up on swarm ConnectionEstablished (#57) — Adds the queue-based trigger so the web actually asks peers for catch-up data on connect. Without this, the web only ever saw real-time Push traffic.
2. chore(fmt): run rustfmt on parse_table_name — CI fmt nit from the earlier round.
3. fix(web): apply ChangesetResponse + bump snapshot timeout to 30s (#59) — Handles the responses (the previous arm was a no-op so the catch-up data was dropped on the floor) and matches the native side's 30s with_request_timeout so catch-up against a populated peer doesn't time out at 10s.

Together these make a fresh WebSyncClient converge with native peers within one round-trip on connect, even with months of historical data.

#57 — version-vector trigger

run_swarm now triggers a VersionVector catch-up request when a non-relay peer's ConnectionEstablished fires, paralleling run_loopback's offline→online edge. The trigger lives on a new pending_version_vectors: Vec<LibPeerId> queue drained at the top of each loop iteration (mirrors pending_announces) — direct synchronous call from handle_event would re-enter wasm_bindgen_futures::Inner::run while holding the swarm borrow.

#59 sub-bug 1 — apply the response

handle_snapshot_event's Message::Response { .. } arm was a no-op marked "PushAck etc. — no-op for now", so ChangesetResponse arrived and was silently dropped. The loopback path doesn't hit this because its responder sends a fresh Push request through out_tx instead of send_response, which routes through the existing Push handler that already calls apply_remote_changeset.

The new handler mirrors the native engine's handle_changeset_response (engine/sync_handler.rs:52-93): verify topic, verify HMAC against bytes that include the real your_last_db_version value, reconstruct the same SyncChangeset shape the inbound-Push path builds, broadcast on inbound_tx, then call apply_remote_changeset — which already persists each winning change, broadcasts on resolved_tx, and updates peer_versions[peer].

#59 sub-bug 2 — 30s snapshot timeout

request_response::Config::default() carries a 10s request timeout. Field repro: against a phone with weeks of synced data, the responder's get_changes_since(0) scan + JSON serialization + HMAC + circuit-relay hop exceeded 10s and surfaced as OutboundFailure: Timeout while waiting for a response. The native side already uses with_request_timeout(Duration::from_secs(30)) on its snapshot behaviour (engine/behaviour.rs:72); web now matches.

Invariants preserved

• HMAC mandatory on ALL message paths. The new outbound request is signed when group_key is configured; the new inbound response handler drops unauthenticated ChangesetResponse silently. Mirrors what the native engine does in both directions.
• db_version=0 semantics. get_peer_version returns 0 for peers never seen before, so a fresh tab's first VersionVector carries your_last_db_version=0 and asks for full history — the only mechanism for initial state transfer.
• Swarm not held across awaits. The drain phase takes &mut swarm for the synchronous send_request, but get_peer_version().await and db_version.lock().await happen before any swarm borrow. The response handler awaits apply_remote_changeset but only with &state + &peer, releasing the swarm borrow first.

Test plan

Automated:

• cargo check --target wasm32-unknown-unknown -p wavesyncdb --features web,dioxus — clean
• cargo check --target wasm32-unknown-unknown -p example-qr-pairing -p wavesync-website — clean
• cargo clippy -p wavesyncdb -p wavesyncdb_derive -p wavesync_relay -- -D warnings — clean
• cargo test -p wavesyncdb --lib — 167 unit tests pass
• cargo fmt --check — clean

Manual repro (requires a browser + relay + at least one peer holding history):

1. Boot wavesync_relay.
2. Boot a native test peer (tests-e2e/test-peer) joined to the same relay+topic+passphrase. Submit a few rows so the peer has history.
3. Open a browser tab on clean IndexedDB and run WebSyncClient::connect_via_relay(...).
4. Before: use_synced_table::<E>(handle) stays empty.
5. After: within one round-trip of relay_connected = true, the console logs swarm: requesting catch-up from <peer> since db_version=0 (we are at 0) followed by WebSyncClient: received ChangesetResponse from <peer> with N changes, and the rows materialize.

Known followup (deliberately not in this PR)

• Reconnect-storm dedup: the queue can fire multiple VersionVectors for the same peer if ConnectionClosed+ConnectionEstablished cycle inside a single loop iteration. Wasteful, not incorrect.
• Response chunking: if real-data catch-ups ever exceed even 30s, split the response into multiple Push request fans instead of one fat ChangesetResponse. Avoids a RAM cliff on very large histories.