fix: wrap any user-module import exception as ModuleLoadError

[EngHabu]

Problem

User modules can raise arbitrary third-party exceptions at import time that don't inherit from RuntimeError / ImportError / etc. The clearest example: google.api_core.exceptions.RetryError (parent: Exception) is raised when a user's module-top-level code calls Google Secret Manager and gcloud credentials have expired. The SDK's import loop only catches a narrow tuple — (ImportError, SyntaxError, NameError, AttributeError, TypeError, ValueError, KeyError, RuntimeError) — so anything else escapes and lands in Sentry as if it were an SDK bug.

PRs #1094 / #1134 / #1146 widened that tuple incrementally. Time to finish the job: anything raised inside importlib.import_module(<user-module>) is, by definition, an error in the user's code or its third-party imports.

Fix

Widen both except clauses in src/flyte/_utils/module_loader.py (file-path branch and directory branch) from the explicit tuple to plain except Exception. Wrap as flyte.errors.ModuleLoadError (a RuntimeUserError already filtered by flyte/_sentry.py:_is_user_error) so deploy surfaces an actionable error and Sentry stops receiving user import-time crashes.

Closes

• FLYTE-SDK-39 — google.api_core.exceptions.RetryError: Timeout of 60.0s exceeded raised from the user's gsm_secrets.set_secrets_as_dict_gcp_flyte during user-module import (expired gcloud creds — gcloud auth application-default login).

fixes FLYTE-SDK-39

Tests

• Added a test that a user module raising a non-RuntimeError Exception subclass at import time is captured as a load failure (or re-raised as ModuleLoadError for the file-path branch).