Fix two latent sync-dispatch bugs; implement updateService

[Quasar-Apps-Agent]

Groundwork for wiring the sync queue (decision 3A). Triaging the write sites first turned up two defects in SyncManager's dispatch — plus a wrong number in the roadmap.

The roadmap's framing was wrong

Track A says "wire queueOperation() into ~34 OfflineException sites across 7 write repos". There are 25 such sites, and only 11 are writes. The other 14 are cache-miss reads ("Bookings not available offline") — nothing to replay, nothing to queue. ROADMAP now carries the corrected list with per-site replay status.

Two latent bugs, neither reachable today

Nothing enqueues anything, which is exactly why these survived. Both had to be fixed before wiring repositories in, since wiring is what makes them reachable.

1. SERVICE/UPDATE replayed as a create. dispatchService shared one branch between CREATE and UPDATE, both calling backendService.createService(dto). A queued service edit — a price change, say — would have appended a second listing instead of editing the first.

The reason it shared a branch: IBackendService had no updateService at all. So this adds one (mirroring updateProvider from #26) and splits the branches. That also lets ServiceRepository.updateService stop returning Result.Error(Exception("Not implemented in backend service")) — the same hard-stub class as updateProvider before #26.

2. PROVIDER_PROFILE would have silently truncated. dispatchProfile decodes every PROFILE payload as a ClientDto, and json is configured with ignoreUnknownKeys = true — so a queued provider update would decode successfully, drop bio/rating/serviceRadius/specializations/employer fields, and write that truncated record to the clients collection. A new EntityType.PROVIDER_PROFILE keeps them apart. dispatchToBackend's when is an expression, so the compiler required the new branch rather than letting it fall through.

Stub consistency

createService returned its input without storing it, so a service created in-session was invisible to every later read, and createBooking resolved price against the seed list only. Now backed by a serviceStore, matching the providerStore/clientStore pattern from #26.

Tests

SERVICE/UPDATE reaches updateService and never createService; PROVIDER_PROFILE round-trips the provider-only fields and never touches updateClient; PROVIDER_PROFILE/CREATE joins the existing non-representable set.

What's next

The five idempotent write sites (updateBookingStatus, cancelBooking, updateClient, updateProvider, updateService) are ready to wire once this lands. Three sites stay blocked for reasons worth stating plainly:

• createBooking — the server assigns the id and the queue has no way to reconcile it back into the optimistic local row, which would keep a fabricated id forever.
• createPayment — would tell a user their payment succeeded while offline with no processor contacted. That compounds the existing client-side SUCCEEDED fabrication rather than fixing it.
• createReview / createService — at-least-once replay can double-post a visible artefact. These need an idempotency key first.

Verification

No Android SDK in this environment, so CI (assembleDebug, allUnitTests, assembleDebugAndroidTest) is the compile signal — please treat a red run as blocking. Base develop @ 2a3e09b.

🤖 Generated with Claude Code

https://claude.ai/code/session_01G6LvbheYzc1mN9toTuuPR5

---

Generated by Claude Code

[Copilot]

Pull request overview

This PR fixes two latent sync-queue dispatch bugs in SyncManager (incorrect service update replay and provider profile payload truncation) and completes the backend/service write path by adding updateService plus consistent in-session service storage in the stub backend, as groundwork for wiring offline-write queue operations (Track A / decision 3A).

Changes:

• Add IBackendService.updateService and implement it in both Firebase and stub backends; update ServiceRepository.updateService to call it and cache the result.
• Fix sync dispatch routing: split SERVICE/CREATE vs SERVICE/UPDATE, and introduce EntityType.PROVIDER_PROFILE + dispatch path to prevent provider payloads decoding as ClientDto.
• Update roadmap framing and add tests covering SERVICE/UPDATE dispatch and PROVIDER_PROFILE dispatch.

Reviewed changes

Copilot reviewed 10 out of 10 changed files in this pull request and generated 1 comment.

Show a summary per file

File	Description
ui/src/main/java/com/example/diamonds/ui/sync/SyncStatusScreen.kt	Adds UI icon mapping for the new PROVIDER_PROFILE entity type.
ROADMAP.md	Corrects Track A framing and enumerates queue-able write sites with replay status.
data/src/test/java/com/example/diamonds/data/sync/SyncManagerTest.kt	Adds test coverage for service-update dispatch and provider-profile dispatch routing.
data/src/main/java/com/example/diamonds/data/sync/SyncManager.kt	Fixes SERVICE/UPDATE dispatch and adds PROVIDER_PROFILE dispatch to avoid provider payload truncation.
data/src/main/java/com/example/diamonds/data/repository/ServiceRepository.kt	Implements updateService by delegating to backend and updating the local cache.
data/src/main/java/com/example/diamonds/data/remote/backend/IBackendService.kt	Introduces the updateService(ServiceDto) backend contract.
data/src/main/java/com/example/diamonds/data/remote/backend/FirebaseBackendService.kt	Implements updateService via Firestore .set() on the service document.
data/src/main/java/com/example/diamonds/data/remote/backend/BackendServiceStub.kt	Adds a mutable serviceStore and implements updateService; createService now stores created services.
data/src/main/java/com/example/diamonds/data/mapper/Mappers.kt	Adds Service.toDto() mapper for the new service update write path.
core/src/main/java/com/example/diamonds/domain/repository/Repositories.kt	Adds EntityType.PROVIDER_PROFILE with documentation explaining why it must be distinct from PROFILE.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

Pull request overview

Copilot reviewed 11 out of 11 changed files in this pull request and generated no new comments.

Suppressed comments (1)

data/src/main/java/com/example/diamonds/data/remote/backend/BackendServiceStub.kt:348

• createService generates ids using System.currentTimeMillis(), which can collide if two creates occur within the same millisecond (possible in tests or fast repeated UI actions). A collision would overwrite the earlier service in serviceStore, producing hard-to-debug behavior. Using a UUID (or a monotonic counter) avoids this class of bug while still staying close to Firebase’s random document ids.

        val saved =
            if (service.id.isBlank()) service.copy(id = "s${System.currentTimeMillis()}") else service