Rethrow process-fatal JVM errors at engine boundaries

[hemju]

Impact

Engine boundaries and long-lived loops broadly catch Throwable, so process-fatal conditions such as OutOfMemoryError and StackOverflowError can be logged and treated like ordinary job/store failures while the JVM continues in an unsafe state.

Recommended handling

• At every intentional catch (Throwable), immediately rethrow VirtualMachineError and ThreadDeath (including through simple wrapper/cause chains).
• Long-lived engine/store loops should normally catch RuntimeException/expected checked exceptions, allowing fatal JVM errors to terminate the thread/process.
• Keep containing user AssertionError and handler-specific linkage/initialization failures where they can safely become FAILED or QUARANTINED jobs; do not convert all Error subclasses into process death.
• Preserve the existing shutdown-specific InterruptedException path and interrupt status.

Acceptance criteria

• Centralize classification in a small internal FatalErrors.rethrowIfFatal(Throwable) helper.
• Call it before logging, interceptor invocation, allocation-heavy failure serialization, or retry logic.
• Add regressions proving VirtualMachineError/ThreadDeath escape handler, interceptor, dispatcher, maintenance, and registry boundaries while ordinary AssertionError remains isolated to one job where intended.
• Document the process-supervisor expectation for fatal JVM termination.