PATCH /integrations/{uniqueKey} rejects an unchanged unique_key when connections exist

Description

Updating an existing integration can fail when the request repeats the integration's current unique_key.

The controller treats every truthy body.unique_key as a rename. If the integration has active connections, the rename guard therefore returns 400 invalid_body even when the requested key is identical to the current key.

Reproduction

Prerequisite: an integration named google-mail with at least one active connection.

PATCH /integrations/google-mail
Content-Type: application/json

{
  "unique_key": "google-mail",
  "credentials": {
    "type": "OAUTH2",
    "client_id": "example.apps.googleusercontent.com",
    "client_secret": "example-secret",
    "scopes": "https://www.googleapis.com/auth/gmail.readonly"
  }
}

Actual result

400 invalid_body — Can't rename an integration with active connections

Expected result

The unchanged unique_key should be treated as an idempotent no-op, and the other requested fields should be updated.

Omitting unique_key from the same request allows the credentials update to succeed, which confirms that the unchanged key triggers the failure.

Likely cause

In patchIntegration.ts, rename validation runs whenever body.unique_key is present:

if (body.unique_key) {
    // uniqueness check
    // active-connections guard
    integration.unique_key = body.unique_key;
}

Suggested fix

Only enter the rename path when the requested value differs from the current one:

if (body.unique_key && body.unique_key !== integration.unique_key) {
    // existing rename validation
}

A regression test could be added to patchIntegration.integration.test.ts: create an integration with an active connection, PATCH it with the same unique_key plus another mutable field, and assert that the request succeeds and applies that field.