Modify instances where Promise.reject() was called with non-Error values
(e.g., strings, plain objects) to consistently use
Promise.reject(new Error(...)) instead.

The main motivation is debugging where errors are coming from:

1. Stack Traces: Error objects automatically capture a stack trace when
   created. This trace shows exactly where in the code the rejection
   originated. Rejecting with strings or other primitives loses this
   vital information.
2. Consistent Error Handling: Downstream .catch() blocks or async/await
   try...catch blocks can reliably expect an object with standard error
   properties (.message, .stack, .name). Handling arbitrary rejected
   types (strings, numbers, objects) complicates error handling logic
   and can lead to runtime errors if code tries to access properties
   that don't exist.
3. Debugging Tools & Libraries: Many debugging tools, error reporting
   services (like Sentry) are optimized to work with Error objects.
   Using them ensures better integration and more informative reporting.
4. Predictability & Convention: It's a widely accepted best practice in
   JavaScript to reject promises with Error objects. Adhering to this
   convention makes the codebase more predictable and easier for
   developers to understand and maintain.

References:

- https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Promise/reject#description
- https://forum.sentry.io/t/javascript-unhandledrejection-timeout/6917