fix: update default CMS type handling in Migration component to ensur…

[AishDani]

…e fallback to DEFAULT_CMS_TYPE

[Copilot]

Pull request overview

Updates CMS type selection in the Migration page to ensure a default CMS type is used when stored/legacy CMS data can’t be resolved, aligning the migration flow with a consistent fallback behavior.

Changes:

• Changes stored CMS lookup fallback from undefined to DEFAULT_CMS_TYPE.
• Simplifies selectedCmsData selection to default to stored CMS (or the default).

Comments suppressed due to low confidence (1)

ui/src/pages/Migration/index.tsx:318

• configCmsData (and its dependency configCmsType) is now computed but never used after simplifying selectedCmsData. This leaves dead code and will likely fail the @typescript-eslint/no-unused-vars rule; either remove these variables or reintroduce logic that uses them.

    // Look up CMS by config's cmsType (same parent-matching logic as LoadSelectCms.filterCMSData)
    const configCmsData: ICMSType | undefined = (configCmsType && validateArray(legacyCmsData?.all_cms))
      ? legacyCmsData?.all_cms?.find(
          (cms: ICMSType) => cms?.parent?.toLowerCase() === configCmsType
        )

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

The comment says config’s cmsType is the source of truth and that selection should prefer config when it differs, but selectedCmsData is now always storedCmsData (falling back to DEFAULT_CMS_TYPE). This appears to drop the config-vs-stored reconciliation behavior and can select the wrong CMS when config changes; either restore the previous parent-matching/precedence logic or update the comments and remove the config lookup entirely to match the intended behavior.

Suggested change

	storedCmsData ?? DEFAULT_CMS_TYPE;
	configCmsData && storedCmsData && storedCmsData.parent?.toLowerCase() === configCmsType
	? storedCmsData
	: (configCmsData ?? storedCmsData ?? DEFAULT_CMS_TYPE);