Since introduction, configd will report exceptions other than ConfigError as type R_ERROR_DAEMON when running config scripts: this has the effect of indicating 'pass-through' execution to the shim, which will re-execute the config mode script within the config session context.

The repurposing of the error name is misleading in this case, but the design is reasonable when the config daemon was still operating with a mixture of scripts running natively and under the daemon: if not a clearly actionable ConfigError, return to the native context. With all scripts now running under the config daemon (T6510), one finds that this behavior can obscure some errors.

This is observed, for example, in the first fix of T6592: running without the config daemon, the error is triggered on the first call of 'commit', but not a subsequent one, hence the pattern above will not raise an error. Since EAFP style within a config script is never exhaustive, unexpected errors should be caught and reported by the config daemon and a commit error code returned to the shim.

This provides a cleaner version of what happens when running without configd: namely, an exception that is not caught by a config script will trigger a traceback and the airbag report, effectively resulting in a commit error.

Note that this is unrelated to the formatting issues of T6605. Moreover, this is a case where formatting should differ between running with/without configd support: errors uncaught by a config script should be clear for debugging and resolution, and (ideally) not make it the point of the user-facing airbag report.

In testing, this refinement has revealed several other obscured bugs; those will be itemized in subtasks for reference.