feat: #36 expose invalidate_forest_cache in fula-flutter + fula-js bindings (0.6.9)

[ehsan6sha]

Fixes #36 — the encrypted client caches each bucket's forest for the client lifetime, so a long-lived session never observes another device's uploads: list_from_forest / get_object_flat keep resolving against the session-stale index (FxFiles repro: a mobile web tab kept showing a 2-file listing indefinitely while desktop had uploaded a third). The dirty-safe escape hatch — EncryptedClient::invalidate_forest_cache / invalidate_all_forest_caches (encryption.rs:9015/:9029) — existed but was unreachable from Dart and JS.

Verified not addressed in 0.6.8 before starting: that release (#35) fixed #34 entirely inside fula-crypto; grep confirms zero invalidate references in either binding crate on main. (0.6.8's two-client reconcile only covers stale writers via the 412 path; pure readers stay pinned forever, exactly as the issue reports.)

What this adds

• fula-flutter (crates/fula-flutter/src/api/forest.rs): invalidate_forest_cache(client, bucket) and invalidate_all_forest_caches(client) — guard read → call through, exactly the issue's sketch. Docs spell out the dirty-safe contract (pending changes are never evicted; flush first) and the intended app wiring (pull-to-refresh / tab-resume / reconnect / SWR revalidation).
• Dart bindings regenerated with the pinned codegen (flutter_rust_bridge_codegen 2.11.1 — same as the hash-consistent release pipeline): invalidateForestCache / invalidateAllForestCaches now exist on lib/src/api/forest.dart. flutter analyze: no issues. Diff is purely additive (new functions + their generated glue).
• fula-js npm parity (crates/fula-js/src/lib.rs): same two exports, invalidateForestCache / invalidateAllForestCaches, and CI's wasm .d.ts export verification now guards both so parity can't silently regress.

Tests

crates/fula-client/tests/issue_36_invalidate_forest_cache.rs — acceptance criteria pinned at the layer both bindings delegate to, against the stateful conditional-PUT mock master (3/3 passing):

1. Cross-device staleness escape (acceptance bullet 1, verbatim): device A lists 2 files → device B uploads a third → A's listing still shows 2 (pins the lifetime-pinning premise the binding escapes) → invalidate_forest_cache + re-list on the same client instance → 3 files, and B's file downloads byte-exactly. No client rebuild.
2. Dirty-safe (acceptance bullet 2): a deferred (unflushed) upload survives invalidation — has_pending_forest_changes stays true and the pending entry stays listed; after flush_forest, invalidation takes effect and the reloaded forest still lists the persisted file.
3. Bulk variant: invalidate_all_forest_caches drops clean forests (they refresh and see the other device's upload) and keeps dirty ones.

crates/fula-flutter/tests/issue_36_invalidate_bridge_test.rs — pins the binding wiring: the functions live on the FRB-scanned crate::api surface and are safe, idempotent no-ops on a client with no loaded forest (the "call unconditionally from every revalidation path" pattern).

Validation

• cargo test -p fula-client --test issue_36_invalidate_forest_cache — 3 passed
• cargo test -p fula-flutter — all suites green incl. the new bridge test
• cargo check -p fula-js --target wasm32-unknown-unknown / -p fula-flutter --target wasm32-unknown-unknown / native — clean
• flutter analyze on packages/fula_client — no issues

Version

0.6.8 → 0.6.9 (workspace, fula-js + fula-flutter crates, fula_client pubspec/podspec, changelog). The fula-js/fula-wasm npm packages keep their own 0.2.x line.

Consumer side: FxFiles' FulaApiService.invalidateForestCache(bucket) (commit cfaa185) is already wired to call this on every SWR revalidation/force path — it picks the Rust call up as soon as 0.6.9 ships, replacing the interim full-client-rebuild workaround.

🤖 Generated with Claude Code