An id reused for another activity is not a copy

Friendica's activity ids are uniqid(): a short prefix and the microsecond. Two of its processes answering two follows at
once gave both Accepts one id, and PrivaPub, queueing each inbox activity once per id, dropped the second as a copy:
that follow stayed pending on our side while Friendica counted the persona as a follower (seen in the town's Friendica
pair). An id that comes back carrying another type, actor or object is now queued apart; a true copy is still dropped.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01LsXgEaXee4GCU1hwYgPJXw

CLAUDE.md

@@ -175,6 +175,8 @@ group www-data and reaches the private mongod; `sudo -u www-data` works too.
      actor's origin now, a Delete of a public or unlisted copy once that origin answers 404 or 410
      (`RemoteActorService.IsGone`), anything else let go. Forwarded copies have their own dedupe key, so a copy that
      failed never hides the author's own delivery;
+   - an activity is queued once per id, but an id that comes back carrying another type, actor or object is a second
+     activity, not a copy (Friendica's ids are `uniqid()`, which two of its processes can share), and is queued apart;
    - the activity's `id`, and any object it creates, updates or deletes, is on the actor's origin; a cross-origin
      object is refetched from its own origin.
 5. **Status codes:**