fix(memory): use plain OS threads for postgres operations to avoid nested runtime panic

[theonlyhennygod]

Summary

• Replace tokio::task::spawn_blocking() with plain std::thread::Builder OS threads in all PostgresMemory trait method implementations (store, recall, get, list, forget, count, health_check)
• Add a run_on_os_thread helper that spawns an OS thread and bridges the result back via tokio::sync::oneshot channel
• The sync postgres crate internally calls Runtime::block_on(), which panics on Tokio blocking pool threads in recent Tokio versions; plain OS threads have no runtime context, avoiding the conflict

Motivation

Fixes #4101 -- the daemon panics on the first incoming request when using the memory-postgres backend with: "Cannot start a runtime from within a runtime."

The initialization in PostgresMemory::new() already correctly used std::thread::Builder (plain OS threads), which is why it worked. But all subsequent operations (store, recall, etc.) used tokio::task::spawn_blocking, whose threads are still associated with the Tokio runtime's blocking pool, triggering the panic.

Risk

Medium -- changes runtime threading for postgres memory operations only. No behavioral changes to query logic or data handling. The pattern matches the existing initialize_client() approach that was already proven to work.

Test plan

• Existing unit tests pass (valid_identifiers_pass_validation, invalid_identifiers_are_rejected, parse_category_maps_known_and_custom_values, new_does_not_panic_inside_tokio_runtime)
• Manual verification with a running PostgreSQL instance using memory-postgres backend
• CI checks (format, clippy, test)