Defer nimsuggest instance init out of MCP initialize handler

[ZoomRmc]

The MCP initialize handler previously awaited initNimsuggestInstances before returning a response. This can be slow or hang (running nimble dump, starting nimsuggest processes). With some harnesses time-outs (30 second for OpenCode), a delayed initialize response causes the MCP connection to fail entirely, before any tool can be used.

MCP protocol expects the server to respond to initialize promptly, then handle the notifications/initialized message. Heavy initialization should happen after the handshake.

Fix: replace await with asyncSpawn so the initialize response is sent immediately and nimsuggest startup proceeds in the background.

[ZoomRmc]

@moigagoo pinging per your request, though there's just 16 open PRs ATM.

This and my other 3 PRs arose when used with OpenCode but since May I moved to another harness and haven't worked much on Nim code, unfortunately. So reproducing this now might be harder, depending on how both projects evolved since then.

All 4 PRs are LLM-assisted (I was a bit annoyed and wanted fast results dealing with a foreign codebase) but are small and focused so hope it's not too much trouble.

[moigagoo]

This PR seems to be a duplicate of #416 , which is merged. This other PR also tried using asyncSpawn first but be cause asyncSpawn means "fire and forget," you lose control over concurrently spawned nimsuggest instances.

The idea to not block while nimsuggest is starting up is spot on and it has been implemented in that PR.