Fix intermittent duplicate Spectora inspectors after reassignment sync

Objective

• After an inspector reassignment is synced from Attik to Spectora, inspectors on the linked Spectora order must match the inspector(s) on the Attik order — not both the old and new inspector.
• Eliminate the intermittent failure (~1 in 5 per customer report) that currently requires a second manual sync to correct Spectora.

Background

• Pat reported that after moving an inspector and syncing from Attik, Spectora will sometimes still show both inspectors on the job.
• The problem is better than before, but still happens about one out of five times. Re-running the sync usually corrects it.
• Chris identified the likely cause as a race condition where the removal and add steps happen too quickly when assignments are changed.
• This is a follow-on to the previously closed reassignment sync work (ATT-1734) and should be tracked here rather than reopening that issue.

Product Decisions

Locked

1. Problem type — This is a sync defect, not expected behavior; relying on a second manual sync is not an acceptable long-term outcome.
2. Job type — Attik-created jobs (jobCreationType === 'attik') with linked Spectora orders — not Spectora-native jobs.
3. Expected outcome — After a successful sync, inspectors on the linked Spectora order match the inspector(s) on the Attik order, with no stale inspectors remaining.
4. User flows in scope — Both calendar drag-to-reassign (event save with Spectora sync) and workorder-level inspector change must be covered.
5. Multi-inspector behavior — When multiple inspectors are assigned, the inspector list on the Spectora order must match what is on the Attik order.
6. Failure visibility — Out of scope. Assignment API failures do not need to surface to users or ops as part of this work.
7. Predecessor — Follow-on to ATT-1734 (Done); do not reopen that issue.

Scope

Backend

• For Attik-created jobs, inspector changes on the workorder trigger syncBarebonesSpectoraJob via the inspection change stream when _inspectorId changes (attik-backend/src/events/streamHandlers/inspectionStream.ts). Assignment reconciliation in syncBarebonesSpectoraJob.ts DELETEs existing Spectora assignments then POSTs the desired set; Spectora is additive, so stale assignments can persist if delete/create does not complete reliably.
• Calendar/event saves pass syncJobSpectora=true on PATCH /event/:id, which calls movingJobInspectorSync with the event only (attik-backend/src/routes/event.ts) — updating the Spectora calendar event via PUT events/{id} without passing the job for order-level assignment reconciliation.
• movingJobInspectorSync.ts also handles full job assignment sync when called with a job (used from PATCH /inspection/:id?syncJobSpectora=true for Spectora-native jobs). Relevant as a reference pattern; primary path for this issue is Attik jobs + linked Spectora orders.

Frontend

• Calendar/event Spectora sync is triggered from attik-frontend/src/components/calendar/ChangedEventIndicator.tsx and attik-frontend/src/components/events/CreateEditEventModal.tsx.
• Workorder-level inspector changes update the inspection record; sync to Spectora is driven by the backend stream for Attik jobs rather than a frontend syncJobSpectora flag.

References

• ATT-1734 — Inspector reassignments do not sync to Spectora (Done; predecessor — complete non-sync vs this intermittent duplicate)
• ATT-371 — Events rescheduled in Attik not rescheduling in Spectora (Done; related calendar sync surface)