feat: support platform resource in migration wizard

[premtsd-code]

Summary

• Add Platforms group (Integrations) to the migration wizard's resource selection
• Augment MigrationResources locally with Platform = 'platform' until the appwrite/console SDK regenerates against the new spec

Test plan

• Open Project Settings → Migrations → New Migration
• Pick Appwrite as the provider, fill in credentials
• On the resource step, confirm the new "Platforms" group appears with the report count
• Run the migration and confirm platforms are migrated

Cross-repo

Depends on:

• Add platform migration support appwrite#11439
• Add platform migration support utopia-php/migration#154

[greptile-apps]

Greptile Summary

This PR wires up a new "Platforms" (integrations) group in the Appwrite migration wizard, letting users migrate web, Flutter, iOS, and Android platform configurations from a source project. It follows the same pattern established by earlier groups (backups, messaging) and adds a documented local augmentation to MigrationResources while the Console SDK is pending regeneration.

• migration.ts: extends the MigrationResource union, initialFormData, ResourcesFriendly, providerResources, and both form-conversion helpers with the integrations/platform group.
• resource-form.svelte: adds integrations to shouldRenderGroup and getReportKey, matching the rendering logic of existing groups.
• importReport.svelte: registers integrations in labelMap and descriptionMap for display in the report UI.

Confidence Score: 4/5

Safe to merge once the dependent backend changes (appwrite/appwrite#11439) are deployed; running against an older source Appwrite could cause the report fetch to fail for all resources.

The changes are self-contained and follow established patterns throughout the codebase. The only noteworthy risk is that 'platform' is now unconditionally included in the Appwrite report request — if a user attempts to migrate from a source Appwrite instance that hasn't received the corresponding backend update, the report API may reject the unknown resource value and block the entire wizard. The type cast workaround is intentional and documented.

src/lib/stores/migration.ts — specifically the providerResources.appwrite array and the temporary type cast that will need cleanup after SDK regeneration.

Important Files Changed

Filename	Overview
src/lib/stores/migration.ts	Adds 'platform' to MigrationResource union, augments MigrationResources locally with a type cast, extends initialFormData/ResourcesFriendly/providerResources/form converters for the new integrations group. Cast is documented but 'platform' is now unconditionally included in the Appwrite report request.
src/routes/(console)/(migration-wizard)/resource-form.svelte	Adds integrations group to shouldRenderGroup and getReportKey; follows the same pattern as all other groups cleanly.
src/routes/(console)/project-[region]-[project]/settings/migrations/(import)/importReport.svelte	Adds integrations entry to labelMap and descriptionMap; straightforward and consistent with other groups.

_{Reviews (1): Last reviewed commit: "feat: support platform resource in migra..." | Re-trigger Greptile}

[greptile-apps]

'platform' unconditionally included in Appwrite report request

providerResources.appwrite is passed verbatim to getAppwriteReport as the resources list. Now that 'platform' is always in that array, any source Appwrite instance that pre-dates the backend change (appwrite/appwrite#11439) will receive an unrecognised resource value. Depending on how the API validates the list, it could reject the entire request and surface "Couldn't load resources" to the user — blocking the whole wizard, not just the Platforms row.

[greptile-apps]

Type cast widens providerResources.appwrite beyond its declared element type

MigrationResources.Platform as AppwriteMigrationResource silences TypeScript's check, so any callsite that receives providerResources.appwrite and narrows on the enum values will now silently encounter a value it wasn't compiled to handle. The comment explains this is intentional, but it's worth tracking as a follow-up: once the SDK is regenerated, remove the cast and the local Platform: 'platform' augmentation so the types are in sync again.