refactor(store): use dedicated thread for signal handling

[xiaguan]

Previous signal handler could potentially deadlock.

This PR uses a thread to process the signal, avoiding this issue.

[xiaguan]

Problem

Our current signal handling logic directly calls cleanupAllResources() inside the signal handler.

This causes a deadlock risk:

[Thread T2 running normally]
          |
          v
 ┌─────────────────────────────┐
 │ Executing: lock(mutex_) ... │
 │             ...             │
 └─────────────────────────────┘
          ^
          |
(SIGINT arrives, kernel interrupts T2)
          |
          v
 ┌──────────────────────────────┐
 │ Run signalHandler(SIGINT)    │
 │   -> calls cleanupAllResources│
 │   -> tries to lock(mutex_)   │
 └──────────────────────────────┘

If the signal interrupts a thread that already holds the mutex, the handler will try to lock the same mutex again → self-deadlock.

[xiaguan]

About the lock and raw ptr, let me think if there's a more elegant solution.

But the basic idea is still to let one thread specifically handle signals. I'll get back to you shortly for review.

[xiaguan]

@ykwd You could review this when you're free.Tks

[ykwd]

After thorough offline discussions, we have concluded that the current approach is acceptable.

[xiaguan]

Once it finishes cleanup, it'll re-raise the signal to terminate the whole process.

[ykwd]

ok. Thx for clarifying

[xiaguan]

There's a really small gap between them. But I think heartbeat may solve this.