fix: make MCP panic logging non-panicking

[mukeshbhandarkar]

Summary

Fixes the recursive panic path described in section 1 of #65.

The MCP panic hook currently logs through eprintln!. If stderr is unavailable or closed, eprintln! can panic while the process is already handling a panic. That re-enters the panic hook and can turn a recoverable panic into a hard abort.

This change makes stderr logging best-effort by writing through a locked stderr handle and ignoring write failures.

Changes

• make mcp_log stderr writes non-panicking
• make the panic hook's direct stderr write non-panicking
• add a Linux regression test using /dev/full to simulate stderr write failure

Scope

This PR intentionally addresses only the panic-hook recursion from #65.

It does not address the separate OOM, segfault, worker lifecycle, or core-dump-location observations from that issue.

Validation

Passed locally:

• cargo fmt --all -- --check
• git diff --check

The targeted runtime test was attempted locally, but the build was blocked before reaching the MCP test by unrelated native dependency build failures in usearch/simsimd and then lbug.

The regression test is included so CI can exercise the panic path in the repository's supported build environment.