Support creating distinct same-participant groups

[kevinwmerritt]

Summary

• add an optional forceNew boolean to POST /api/v1/chat/new
• restrict forced creation to multi-participant iMessage chats using method: "private-api"
• generate a server-side UUID creation token so clients do not need to understand private group-matching metadata
• support silent forced creation when no first message is supplied and verify the returned chat GUID persisted to chat.db
• bundle the corresponding macOS 11+ development helper

Existing behavior is unchanged when forceNew is absent or false.

Stack and dependencies

• temporarily includes Fix development production build and migration startup #840, which fixes the development production build and migration startup
• helper runtime compatibility: Resolve ChatKit classes dynamically bluebubbles-helper#70
• helper forced-group implementation: Support forced creation of distinct group chats bluebubbles-helper#71

This PR targets development because GitHub cannot base an upstream PR on a branch that exists only in a contributor fork. Once #840 merges, its commits will already be present in development and this diff will collapse to the server feature layer.

Related implementation evidence

Linq documents the same externally visible matching behavior in Creating a second group with the same participants: repeating the same sender and exact recipient set returns the existing chat ID, while excluding the existing group from matching allows a separate chat ID to be created. Their documented workaround is to name the existing group before creating the next one.

That independently documented behavior is consistent with the IMCore/ChatKit roster-matching behavior addressed here. This implementation exposes an explicit forced-creation option instead of requiring callers to rename an existing group first.

API example

{
  "addresses": ["person-a@example.com", "+15551234567"],
  "method": "private-api",
  "forceNew": true
}

message remains optional only for forced creation. If supplied, the existing create-and-send response path is preserved.

Verification

Tested on macOS 15.7.7 with the development server/helper:

• an existing roster produced a distinct group chat GUID
• silent creation persisted to chat.db
• creation with a first message kept that message in the newly created thread
• helper Release arm64e workspace build passes with Xcode 16.4
• focused ESLint checks pass
• production webpack build passes
• Electron packaging reached DMG creation; final hdiutil execution is unavailable in the current build environment