Fix error handling to distinguish Error objects from primitive throws

[kmahmood74]

Summary

This PR improves JavaScript error handling in the TS interpreter to properly distinguish between Error objects and primitive throws:

• Error objects (created via new Error()) are now kept as JSCustomException to preserve their object nature and allow access to the .message property
• Primitive throws (strings, numbers, etc.) are unwrapped to their raw values for proper catch block handling
• Added comprehensive test coverage for both error types and mixed scenarios

Changes

• Added isErrorObject flag to JSCustomException class to track error creation method
• Updated try-catch handler in newjs_interpreter.dart to conditionally wrap/unwrap based on error type
• Added 7 new test cases covering Error objects, primitive throws, rethrowing, and mixed scenarios
• Updated .gitignore to exclude Flutter-generated files in example apps

Test plan

• All existing tests pass
• New tests validate Error object .message property access
• New tests validate primitive throw unwrapping
• Tests cover error rethrowing and mixed scenarios

🤖 Generated with Claude Code

[sharjeelyunus]

LGTM. However, these changes should live in packages/ensemble_ts_interpreter rather than modules/ensemble_ts_interpreter/.

The current ensemble runtime uses the new path (packages/ensemble_ts_interpreter). The older path is only retained for backward compatibility and will be removed once we confirm it’s no longer in use. These new directories were introduced as part of the effort to make each package standalone and publishable to pub.dev.

For more details, please refer to the Packages Migration documentation (still in progress) as we continue moving all ensemble packages to standalone, pub.dev–published packages:
PACKAGES_MIGRATION.md