Fix duplicate Foundry actor on createActor sync race

Symptom: creating one character actor in Foundry produced two actors
sharing the same chronicle entityId, with chronicle holding a single
entity. The dashboard reported both as synced because both carried the
flag, but they were competing for the same chronicle row.

Cause: when _handleCreateActor POSTs the new entity, chronicle's
entity.created WebSocket broadcast fires before (or alongside) the
POST response. _onCharacterCreated runs, finds no Foundry actor with
the entity's id flag (the originator hasn't returned yet to set it),
and creates a fresh actor. The originator then sets the flag on its
own actor too, leaving two flagged actors.

Fix: track Foundry-originated creates in an in-flight Map keyed by
actor.id holding actor.name. Set on entry to _handleCreateActor,
clear in finally. _onCharacterCreated checks the in-flight names; on
match, it skips creation and lets the originating handler link the
existing actor when its POST returns. Match by name because the
incoming Foundry actor doesn't have the new chronicle entity id yet.

Existing duplicates from before this fix must be cleaned up manually
by deleting the newer of each duplicate pair.

Author: claude

scripts/actor-sync.mjs

@@ -33,6 +33,15 @@ export class ActorSync {
     /** @type {boolean} Suppress hook processing during sync-initiated changes. */
     this._syncing = false;
 
+    /**
+     * Tracks Foundry-originated creates whose POST is in flight.
+     * Maps actor.id → actor.name. Used to suppress the WS-driven
+     * `_onCharacterCreated` from spawning a duplicate Foundry actor when
+     * `entity.created` arrives before our POST returns.
+     * @type {Map<string, string>}
+     */
+    this._inFlightCreates = new Map();
+
     /** @type {object|null} Loaded system adapter module. */
     this._adapter = null;
 
@@ -192,6 +201,21 @@ export class ActorSync {
     );
     if (existing) return;
 
+    // Race guard: a Foundry-originated POST for this name is in flight.
+    // The originating handler will set the entityId flag once its POST
+    // returns; creating another actor here would produce a duplicate
+    // Foundry actor sharing the same chronicle entity. Match on name
+    // because we don't yet know the new entity's ID on the Foundry side.
+    for (const inFlightName of this._inFlightCreates.values()) {
+      if (inFlightName === entity.name) {
+        console.debug(
+          `Chronicle: Skipping WS-driven actor create for "${entity.name}" — ` +
+          `Foundry-originated POST is in flight; the originating handler will link it.`
+        );
+        return;
+      }
+    }
+
     try {
       this._syncing = true;
 
@@ -344,6 +368,13 @@ export class ActorSync {
     // Skip if already linked (came from Chronicle).
     if (actor.getFlag(FLAG_SCOPE, 'entityId')) return;
 
+    // Mark this Foundry-originated create as in-flight so the WS-driven
+    // _onCharacterCreated can skip the matching `entity.created` broadcast
+    // that arrives before our POST returns. The flag is set after the POST
+    // succeeds; without this guard, the WS handler doesn't see the flag yet
+    // and creates a duplicate Foundry actor.
+    this._inFlightCreates.set(actor.id, actor.name);
+
     try {
       const fields = this._adapter.toChronicleFields(actor);
 
@@ -388,6 +419,8 @@ export class ActorSync {
       }
     } catch (err) {
       console.error('Chronicle: Failed to push new actor to Chronicle', err);
+    } finally {
+      this._inFlightCreates.delete(actor.id);
     }
   }