feat: Use p/future for async handler execution

[BuddhiLW]

Summary

Use p/future instead of p/promise for handler execution to enable true concurrent request processing.

Changes

;; Before
result-promise (p/promise
                 (receive-request method context params))

;; After  
result-promise (p/future
                 (discarding-stdout
                   (receive-request method context params)))

Benefits

1. Concurrent Request Handling

With p/promise, handlers run synchronously on the request processing thread, blocking subsequent requests. With p/future, handlers execute on a thread pool allowing multiple requests to be processed in parallel.

Use case: MCP servers with swarm/multi-agent orchestration where multiple Claude instances make concurrent tool calls.

2. Stdout Protection

The discarding-stdout wrapper prevents accidental println or logging statements from corrupting the JSON-RPC channel (which uses stdout for communication).

3. Non-blocking Event Loop

The main message processing loop stays responsive even when handlers are slow, preventing request queue buildup.

Testing

Tested with emacs-mcp swarm feature:

• Spawned 2 concurrent agents
• Both handlers executed in parallel ("working": 2)
• Results collected successfully

Backward Compatibility

This change is backward compatible - existing single-request usage works identically, with the added benefit of non-blocking execution.

[BuddhiLW]

I've cleaned up this PR to include only the essential changes.

Before: 68 lines changed across multiple unrelated indentation adjustments

After: 10 lines changed in a single focused location (pending-received-request function)

The actual fix

;; Before
result-promise (p/promise
                 (receive-request method ...))

;; After
result-promise (p/future
                 (discarding-stdout
                   (receive-request method ...)))

Why this matters

1. p/future vs p/promise: Enables handlers to run on a thread pool instead of blocking the request processing thread
2. discarding-stdout: Prevents accidental println from corrupting the JSON-RPC channel (which uses stdout)

Use case

This fix is critical for MCP (Model Context Protocol) servers where:

• Multiple concurrent tool calls need parallel processing
• Stdout must remain clean for JSON-RPC communication

Tested with emacs-mcp swarm feature - concurrent agents now work correctly.