create_row/node/edge/vector and all bulk_create_* gRPC handlers were calling
synchronous store write functions (which acquire segment_arc.write()) directly
inside async fn bodies.  Under high write concurrency (16+ parallel clients)
all Tokio worker threads would block waiting for the parking_lot write lock,
starving async I/O and causing request latency to explode.

Fix: wrap each write handler body in tokio::task::spawn_blocking so the write
lock contention happens on the blocking thread pool (512 default threads) rather
than on the async executor's worker threads.  Read/query handlers are unchanged.