Handle Errors from execution without killing the channel loop #132

[paulk-asert]

Fixes #132.

An Error escaping evaluation pierced both catch (Exception) layers (BaseKernel.handleExecuteRequest and the ShellChannel dispatcher), reached Loop.run's catch — which rethrows when no onError callback is registered — and killed the shell-channel loop thread: no execute_reply, kernel permanently unresponsive. For JShell evaluation this is largely masked (user throwables arrive wrapped in EvalException), but kernel-side code (rendering, magics, extensions) and non-JShell kernels built on jjava-jupyter hit it directly.

Two defensive layers, per the issue:

• BaseKernel: the execute/inspect/complete handlers now catch Throwable, so the user sees a proper error (PublishError + error reply) and the kernel keeps running. ErrorReply.of, PublishError.of and ErrorFormatter.format widen from Exception to Throwable accordingly (source-compatible for existing callers; ErrorFormatter implementors need the wider signature).
• ShellChannel: the dispatcher's per-message guard widens to Throwable as a last resort, so nothing a handler throws can take down the loop.

New BaseKernelErrorHandlingTest drives handleExecuteRequest with an evaluator throwing AssertionError, NoClassDefFoundError, and (as the control) RuntimeException, asserting an error is published and replied in each case. Verified the new tests fail against the previous code (the two Error cases escape raw) and pass with the fix; full jjava-jupyter suite: 154 tests green.