Revert content-migration error-capturing workaround once adapt-migrations propagates errors

[taylortom]

Follow-up

runContentMigration (lib/utils/runContentMigration.js) currently works around adaptlearning/adapt-migrations#65, where migrate() swallows failed migration steps (logs + rolls back, but resolves successfully without throwing). Because no error is thrown, the existing try/catch in migrateCourseData (import) and migrateExistingCourses (framework update) never fired, so a failed content migration was silently treated as a successful import.

As a stopgap, runContentMigration wraps the adapt-migrations logger with createErrorCapturingLogger and throws if any error-level logs are emitted during migrate().

Action when adaptlearning/adapt-migrations#65 is merged & released

Once migrate() propagates the error itself (throws / returns an error state), revert the workaround back to standard try/catch:

• Bump the adapt-migrations dependency to the version that propagates migration errors
• In lib/utils/runContentMigration.js, remove the createErrorCapturingLogger wrapper and the post-migrate() error check; restore plain await migrate({ journal, logger })
• Delete lib/utils/createErrorCapturingLogger.js, its barrel export in lib/utils.js, and tests/utils-createErrorCapturingLogger.spec.js
• Remove the swallowed-error test case from tests/utils-runContentMigration.spec.js (the existing try/catch in the callers will once again surface the thrown error)
• Confirm migrateCourseData still raises FW_IMPORT_MIGRATION_FAILED on a failing migration

References

• Root cause: migrate() swallows failed migration steps instead of propagating the error adaptlearning/adapt-migrations#65

[taylortom]

Workaround implemented in #218 / #219. This issue tracks reverting it to standard try/catch once adaptlearning/adapt-migrations#65 is merged and released.