Add Email Templates migration

[premtsd-code]

Summary

• Adds TYPE_PROJECT_EMAIL_TEMPLATE to GROUP_PROJECTS_RESOURCES for migrating the project's per-locale email template overrides.
• Source (Sources/Appwrite) reads templates via Project::listEmailTemplates (offset-paginated; not cursor) and emits one EmailTemplate resource per (type, locale).
• Destination (Destinations/Appwrite) replays them via Project::updateEmailTemplate for each entry.
• No new group: per the abnegate review on feat(migration): add project-level resource migrations #186, project's own email copy is just another per-project singleton — it belongs in GROUP_PROJECTS alongside PROJECT_VARIABLE / PROJECT_PROTOCOLS / PROJECT_LABELS / PROJECT_SERVICES.

Test plan

• CI lints + tests green
• E2E testAppwriteMigrationEmailTemplates (in appwrite/appwrite) passes

[greptile-apps]

Greptile Summary

This PR adds email template migration support (TYPE_PROJECT_EMAIL_TEMPLATE) to the Appwrite source/destination adapters, following the existing per-project singleton pattern used by services, labels, and protocols.

• New EmailTemplate resource (Resources/Templates/EmailTemplate.php): models one (templateId, locale) pair; fromArray/jsonSerialize round-trip cleanly.
• Source (Sources/Appwrite): offset-paginated exportEmailTemplates loop plus a report-count probe via listEmailTemplates.
• Destination (Destinations/Appwrite): createEmailTemplate uses a direct DB read-then-merge strategy (bypassing the SDK's SMTP-gated updateEmailTemplate) to write into the project's templates map, but is missing the purgeCachedDocument call that all sibling methods require after touching the projects document.

Confidence Score: 4/5

The change is otherwise well-structured, but the missing cache invalidation in createEmailTemplate means all-but-the-last template are silently dropped when a project has more than one custom template.

Every other method in the destination that performs a read-then-merge on the projects document calls purgeCachedDocument immediately after updateDocument. createEmailTemplate skips this step. Because templates are written one at a time through the callback, each call reads a cached snapshot that does not include the prior write, then overwrites the DB with only the current template. The net result is silent data loss for every template except the last one migrated.

src/Migration/Destinations/Appwrite.php — the createEmailTemplate method needs a purgeCachedDocument call after updateDocument.

Important Files Changed

Filename	Overview
src/Migration/Destinations/Appwrite.php	Adds createEmailTemplate using direct DB read-then-merge pattern, but is missing the purgeCachedDocument call that every other project-document-mutating method includes, causing silently lost templates when multiple templates are migrated.
src/Migration/Resources/Templates/EmailTemplate.php	New resource class for per-(type, locale) email template; constructor, getters, fromArray, jsonSerialize, getName, and getGroup all look correct.
src/Migration/Sources/Appwrite.php	Adds offset-paginated exportEmailTemplates and report count via listEmailTemplates(…, total: true). The named total argument may not exist in the SDK (caught silently), but the export loop itself is correct.
src/Migration/Resource.php	Adds TYPE_PROJECT_EMAIL_TEMPLATE constant and includes it in the resource-name list — straightforward.
src/Migration/Transfer.php	Adds TYPE_PROJECT_EMAIL_TEMPLATE to both GROUP_PROJECTS_RESOURCES and the all-resources list — consistent with existing constants.
tests/Migration/Unit/Adapters/MockDestination.php	Adds TYPE_PROJECT_EMAIL_TEMPLATE to the mock destination's supported types list.
tests/Migration/Unit/Adapters/MockSource.php	Adds TYPE_PROJECT_EMAIL_TEMPLATE to the mock source's supported types list.

_{Reviews (5): Last reviewed commit: "Apply suggestion from @abnegate" | Re-trigger Greptile}