Issue Summary:

There is a migration-scope identity/reuse issue in MCS/TCC where migrations triggered via BACKUP API (with an external/empty source location) are incorrectly sharing, reusing, or overwriting the scope of BRIE backup migrations (which use a populated cloud source location).

As a result:

• The migration-details response payload returns source._type: external without source.cloudId (both source.cloudId and sourceCloudUrl evaluate to null).

• BRIE encounters a deserialization failure when attempting to read previous migrations because it expects a valid cloud source object (_type: cloud with a populated cloudId).

• All subsequent backup operations (new backup creation, scheduled policy execution, and lifecycle actions like cancellation) get stuck in "In Progress" / "Not active" state.

• Current Operational Overhead: Support / Engineering must perform a manual forceReset on migration scopes for each impacted customer tenant.

Steps to Reproduce / Trigger Condition

1. Trigger a standard Confluence Cloud backup via BRIE UI/Scheduler (creates migration with _type: cloud and valid source cloudId).

1. Trigger an operation/migration via the BACKUP API against the same destination scope (uses _type: external / empty source).

1. MCS/TCC reuses or maps both operations to the same migration scope identifier.

1. BRIE attempts to read/poll migration details for the existing scope.\

Expected Behavior

• Strict Scope Isolation: Migration Control Service (MCS/TCC) should maintain distinct, isolated migration scopes for incompatible location types (external vs. cloud) so they never share or overwrite state.

• Payload Integrity: The migration-details response for BRIE backup migrations should always retain source._type: cloud along with a valid, non-null source.cloudId and sourceCloudUrl.

• Healthy Lifecycle Management: BRIE should successfully read and deserialize migration metadata from previous runs without encountering exceptions.

• Normal Backup Execution: Customers' automated and manual backup jobs should complete, show accurate active statuses, and allow standard lifecycle actions (e.g., cancellation or retries) without manual intervention.

Actual Behavior

• Scope Collisions: MCS/TCC incorrectly reuses/shares the same migration scope identifier across both BACKUP (BRIE) and BACKUP API migrations.

• Scope Overwriting & Null Fields: The migration scope state is overwritten with source._type: external, resulting in source.cloudId and sourceCloudUrl evaluating to null.

• Deserialization Failure: When BRIE attempts to fetch migration details, it encounters a deserialization error because it expects a valid cloud source object (_type: cloud with a populated cloudId).

• Wedged Backup Lifecycle: Backup policies enter a broken state (showing "Not active" or perpetually stuck "In Progress"), blocking new backups and cancellations.

• Manual Reset Required: Operations remain blocked across affected customer tenants until engineering/support manually executes a forceReset on the scope.

Workaround:

NA