feat: add store-level getUndoPath for handle-driven navigation-aware undo

[TrystonPerry]

Problem

Handle writes (update/add/remove) push undo actions through makeOnPushUndo, which never set UndoAction.path. So action.path was always undefined for handle-driven undo and onNavigate never fired — only a manual undoManager.push({ path }) could trigger navigation-aware undo, which defeats the point.

Fix

Add a store-level getUndoPath?: () => string | undefined callback on FirestateConfig and FirestateProviderProps; makeOnPushUndo now stamps path: store.getUndoPath() onto every handle-pushed action, so the app supplies the router path at write time and onNavigate works for ordinary writes. It uses the same runtime-replace plumbing (setGetUndoPath + useEffect) as onNavigate/onError, and existing group-merge semantics are untouched (merged groups keep the newest action's path). Covered by store-level unit tests and an end-to-end integration test through the real makeOnPushUndo path, plus README docs; full suite passes (258 tests) and typecheck/build are clean.

Note

Add getUndoPath callback to stamp router path onto handle-driven undo actions

• Adds getUndoPath?: () => string | undefined to FirestateConfig, FirestateStore, and FirestateProvider, allowing callers to supply a function that returns the current router path.
• When a handle write pushes an undo action in shared-subscription.ts, the path from store.getUndoPath() is stamped onto the action so that onNavigate is invoked on undo/redo.
• FirestateStore exposes setGetUndoPath to replace the resolver at runtime without recreating the store; FirestateProvider calls this in an effect when the prop changes.
• Merged undo groups retain the newest action's path.

📊 Macroscope summarized 2261e2a. 5 files reviewed, 0 issues evaluated, 0 issues filtered, 0 comments posted

🗂️ Filtered Issues

No issues evaluated.