Implement board synchronization functionality

[tomivm]

Enhance board synchronization by implementing the syncBoards action, updating the reducer to manage sync status, and refining board identification logic. This update improves the handling of locally created boards and integrates detailed synchronization states. Tests have been adjusted to ensure accuracy in board classification and synchronization processes.

NOTE: The original descriptionwas EDITED

Close #2096

[tomivm]

I use Claude Code to review the changes and I get:

1. ADD_BOARDS missing syncStatus (Board.reducer.js:134-138)
   - Boards from server are added without syncStatus, causing inconsistent behavior
   - Should default to SYNC_STATUS.SYNCED for remote boards
2. Incorrect axios error property (Board.actions.js:638, 685)
   - Uses e.status instead of e.response?.status
   - 404 errors won't be properly detected
3. Dead/incomplete code in applyRemoteChangesToState (Board.actions.js:629-643)
   - Commented-out dispatch logic
   - No handling when API.getBoard() succeeds

Important Issues (Should Fix)

1. Missing tests for syncBoards and applyRemoteChangesToState - the core sync logic
2. Sequential API calls could be parallelized with Promise.allSettled (not sure maybe intentional)

What's Done Well

• Clear PULL-then-PUSH architecture
• Good test coverage (111 tests pass)
• Proper syncStatus and isSyncing state tracking
• Well-documented functions with JSDoc
• Clean selectors with tests

Recommendations

1. Fix axios error property access
2. Handle syncStatus in ADD_BOARDS
3. Clean up the commented code block
4. Add the missing orchestration tests

[tomivm]

this names are confusing me

[RodriSanchez1]

Do you have any suggestion?

[RodriSanchez1]

Sync Follow-Up Issues

Issues to address in future PRs after the initial syncStatus implementation.

---

1. Handle 409 errors to prevent infinite retry loop

Problem: When a board push fails with 409 (server validation error), the board stays PENDING forever. The user permanently sees "unsynced changes" with no way to resolve it.

Affected code:

• pushLocalChangesToApi catch block — Board.actions.js:717

Expected behavior:

• 409 (validation rejection): Stop retrying. Pull server version if available, mark SYNCED
• Transient errors (500, network): Keep PENDING for natural retry on next sync

---

2. Boards created while logged out get syncStatus: PENDING

Problem: CREATE_BOARD reducer unconditionally sets syncStatus: PENDING. These boards have email: '' which is now correctly blocked by the push filter. However, they remain stuck as PENDING locally with no way to resolve — the user sees "unsynced changes" even though the boards will never be pushed.

Affected code:

• CREATE_BOARD reducer — Board.reducer.js:262

Possible solutions:

• Don't set syncStatus in CREATE_BOARD when not logged in (pass auth context to action)
• On login, adopt orphaned PENDING boards (set their email to the logged-in user)
• On login, clear syncStatus from boards with empty email

---

3. Tile operations don't mark the parent board as PENDING

Problem: CREATE_TILE, DELETE_TILES, and EDIT_TILES modify a board's tiles but do NOT set syncStatus: PENDING on the parent board. For logged-in users this is handled by updateIfFeaturedBoard() in the container which calls updateBoard(). However, for logged-out users, tile changes modify the board content without entering the sync system — so if the user later logs in, those tile changes are invisible to sync and could be overwritten by the server version on the next pull.

Affected code:

• tileReducer — Board.reducer.js:78-101
• CREATE_TILE / DELETE_TILES / EDIT_TILES cases — Board.reducer.js:284-304

Related to: Issue #2 and #4 — part of the broader unlogged user modifications problem.

---

4. Identity boundary on login

Problem: When a user with an existing account logs in on a device that has local modifications, those changes could conflict with their server state.

Expected behavior:

• First-time signup: local changes should follow the user
• Existing account login: server state should take priority, or user should be prompted

Possible solutions:

• On existing-account login, reset local state to server state
• Prompt the user to choose between local and server versions