Add user notification for background child transfer failures

[malibio]

Summary

When createNode() transfers children to the database in the background, failures are logged to console but users are not notified. This can lead to silent data inconsistencies that confuse users.

Current Behavior

In reactive-node-service.svelte.ts, the background child transfer has proper rollback logic but no user notification:

Promise.resolve().then(async () => {
  try {
    await sharedNodeStore.waitForNodeSaves([nodeId]);
    for (const child of children) {
      const { moveNode } = await import('$lib/services/tauri-commands');
      await moveNode(child.id, nodeId);
    }
  } catch (error) {
    console.error('[createNode] Failed to transfer children to database, rolling back:', error);
    for (const child of children) {
      structureTree.moveInMemoryRelationship(nodeId, afterNodeId, child.id);
    }
    // TODO: Emit error event for UI notification (toast/banner)
  }
});

Expected Behavior

When child transfer fails:

1. Rollback happens (already implemented)
2. User sees a toast/banner notification explaining the issue
3. User can retry or take corrective action

Acceptance Criteria

• Create an event/notification system for async operation failures
• Show toast notification when child transfer rollback occurs
• Message should be user-friendly (e.g., "Changes couldn't be saved. Please try again.")
• Consider adding a retry action to the notification

Technical Notes

• Location: packages/desktop-app/src/lib/services/reactive-node-service.svelte.ts:338-365
• Found during code review of PR Fix: Enter key, indent/outdent, and SSE sync issues #655
• Related to optimistic UI pattern with error recovery

Labels

enhancement, ux, error-handling

[malibio]

Frontend baseline: 133 files, 3866 tests passed

[malibio]

Heads-up on scope (from #1228 audit triage)

Noticed the branch is worktree-issue-656-toast-notifications — flagging a scope + collision concern before this goes too far. Pivot only if it applies to what you're actually building.

Keep this narrow — reuse the existing notification infra, don't build a parallel one

There's already a notification system from #1231:

• packages/desktop-app/src/lib/stores/conflict-notifications.svelte.ts — ConflictNotificationStore (.add(), .dismiss(), capped at 10, conflictType: 'concurrent-edit' | 'version-mismatch' | 'deleted-node')
• packages/desktop-app/src/lib/components/conflict-toast.svelte

#656's actual ask is one notification: surface the background child-transfer failure (the TODO(#656) at reactive-node-service.svelte.ts:388, inside the rollback catch). Please reuse/extend the existing store rather than introduce a second, generic toast system.

The one legitimate extension

A child-transfer failure isn't really a conflict, so it doesn't fit the current conflictType enum cleanly. The small, justified change is either:

• add a variant (e.g. 'background-failure') to the existing enum, or
• rename the store/type to something neutral (notificationType) if that reads better — but keep it one store.

⚠️ Collision to avoid

#1268 (C5) is filed and depends on ConflictNotificationStore staying intact — it routes daemon OCC version-conflicts through 'version-mismatch'. If #656 forks into a separate generic toast system or heavily refactors the conflict store, it'll collide with C5. A minimal extension (add a variant) is fine; a parallel system or a big rename-refactor is not — if you want a truly generic toast framework, that's a separate issue, not #656.

Also (forward-looking, no action needed now)

This catch-block notification is the same code C3c (atomic child-transfer, not yet filed) will eventually rewrite. Your notification logic carries over — C3c will just retrigger it from the atomic RPC's error path instead of the loop's catch. So this is not wasted work; just keep the emit easy to relocate.

tl;dr: surface the one failure, reuse the existing conflict-notification store (extend the enum if needed), don't build a parallel toast system (protects #1268).