Bring Try Catch to the Engine level with direct error handling and engine.error() engine.warn() instead of logs

or, better:

Why throw logs(...) is wrong (and why we need engine.error() / engine.fail())

Problem

Using throw logs('error', ...) looks like a shortcut to "log + stop execution", but it breaks error semantics and produces unstable runtime behavior (ghost 500s, missing stacks, inconsistent middleware flow).

logs() is a side-effect, not an error object

logs() exists to emit information (console/audit/file) and possibly trigger a policy action. It is not guaranteed to return an Error.

So this pattern is fundamentally unsafe:

throw logs('error', 'something went wrong', true)

Because throw expects a thrown value that behaves like an error. If logs() returns:

• undefined → you effectively do throw undefined
• a string → you lose stack trace + structured error handling
• a non-Error object → instanceof Error fails and error flow becomes inconsistent

Consequences of throwing non-Error values

Throwing a string/undefined/non-Error causes real operational problems:

• No stack trace: you lose err.stack, so debugging becomes guesswork.
• No reliable typing: err instanceof Error fails; catch blocks and middleware error handlers cannot distinguish real failures from random thrown values.
• Broken middleware flow: frameworks (Express/Koa/Fastify/native adapters) expect Error-like objects for next(err) or centralized error handling.
• Audit becomes misleading: the log exists, but the engine lacks the real error object that explains where and why the failure happened.

What we actually want

We want one primitive that:

1. Captures a real stack trace
2. Logs/audits consistently
3. Respects engine policies (fatal vs non-fatal)
4. Returns or throws a real Error

Why engine.* must own the trace

Only the engine can enforce consistent error semantics across all packages and adapters.

Expected migration outcome

Packages stop throwing strings or throw logs(...) and instead rely on engine-level error primitives.