Ensure loggers receive Throwable objects to prevent crashes

[AciDCooL]

Description

This PR fixes a critical application crash that occurs whenever Organizr attempts to log an error message as a string rather than an Exception object.

The Problem

If a backend error occurs (for example, a database constraint or permission issue) and Organizr attempts to log it, the UI throws a Slim ApplicationError and completely halts:

Type: InvalidArgumentException                                                                                                                           
Message: Please give the exception class to the Nekonomokochan\PhpJsonLogger\Logger::error                                                               
File: /config/www/organizr/api/vendor/nekonomokochan/php-json-logger/src/PhpJsonLogger/Logger.php                                                        

(Or similarly for array_column() when it silently fails further down the stack due to the same logger issue).

This happens because the recently integrated Nekonomokochan\PhpJsonLogger\Logger package strictly requires its error() , critical() , alert() , and emergency() methods to receive a PHP \Throwable (Exception) object as the first parameter.

However, throughout the Organizr codebase, it is very common to pass simple text strings or arrays into the logger (e.g., $this-

setLoggerChannel('User')->error('Failed to update user: ' . $e->getMessage()); ). When the string reaches the underlying JSON Logger, it throws an InvalidArgumentException , crashing the application and completely hiding the actual original error.

The Fix

Instead of tracking down and modifying every single error() or critical() call across the entire codebase to pass an Exception, this PR updates the global logging wrappers in api/functions/log-functions.php .

The wrapper methods ( error , critical , alert , and emergency ) now proactively verify if the passed $msg is a \Throwable . If it is not, they safely wrap the string (or JSON-encoded array) into a new \Exception on the fly before passing it to the logger.

This bulletproofs the codebase, allowing developers to continue passing simple string messages to the logger without inadvertently triggering application-breaking crashes.