ACP server: parse error response uses hardcoded request ID 0 instead of null per JSON-RPC 2.0 spec

[Felicity73]

Bug Description

In cortex-engine/src/acp/server.rs, both the stdio transport (line 64) and HTTP transport (line 185) return parse error responses with a hardcoded request ID of AcpRequestId::Number(0). Per JSON-RPC 2.0 specification Section 5, when the request ID cannot be determined (e.g., due to a parse error), the id field MUST be Null.

Evidence

server.rs line 62-66 (stdio transport):

Err(e) => {
    let err_response = AcpResponse::error(
        AcpRequestId::Number(0),  // BUG: should be Null
        AcpError::parse_error(e.to_string()),
    );
    Self::write_to_stdout(&err_response).await?;

server.rs line 183-187 (HTTP transport) — same pattern:

Err(e) => {
    let err_response = AcpResponse::error(
        AcpRequestId::Number(0),  // BUG: should be Null
        AcpError::parse_error(e.to_string()),
    );

Impact

0 is a valid request ID. A client that sends a legitimate request with id: 0 will incorrectly correlate a parse error from a different malformed request with its own valid request. In multiplexed or pipelined scenarios, this misattribution causes the client to treat its in-flight request as failed when it was actually still pending. The JSON-RPC 2.0 spec prescribes null for exactly this reason.

Expected Fix

Use AcpRequestId::Null (or equivalent) for parse error responses:

let err_response = AcpResponse::error(
    AcpRequestId::Null,
    AcpError::parse_error(e.to_string()),
);