feat(saas-migration): persist export/backup result via EntityFileStorage

[marioserrano09]

Summary

• The export/backup ZIP produced by the SaaS Migration module is no longer left as a raw file on local/container disk. It's still assembled in a local transient working file (AccountMigrationProperties.outputDirectory), but is only uploaded to EntityFileService/EntityFileStorage (local safe dir, S3, Buckie, …) after the pipeline finishes successfully — the local copy is deleted right after, win or lose.
• A job never reports COMPLETED without a persisted, downloadable result: if the upload to EntityFileStorage fails, the job is marked FAILED instead.
• AccountMigrationJob.resultPath (raw filesystem String) is replaced by resultFile (EntityFile FK, eager-fetched), associated with the job itself.
• GET /jobs/{jobId}/download now streams via StoredEntityFile.toResource() (through the new AccountMigrationJobService.downloadResult()), so it works transparently regardless of which storage backend is configured — no more FileSystemResource over a raw path.
• CLONE is unaffected: it already used a JVM temp file that's deleted in a finally block and never exposed for download.
• ARCHITECTURE.md updated (new §7.1, diagrams, DB schema, roadmap) to document the new persistence flow.

Test plan

• mvn -pl extensions/entity-files/sources/core,extensions/saas/sources,extensions/saas/sources/migration -am install -DskipTests — reactor builds clean with the new entity-files dependency wired in.
• mvn -pl extensions/saas/sources/migration test — all 75 existing unit tests pass unchanged.
• Manual smoke test in a host app: run an EXPORT/BACKUP job end-to-end and confirm GET /jobs/{jobId}/download streams correctly against each configured EntityFileStorage backend (local, S3, Buckie).

🤖 Generated with Claude Code