Issue: Incorrect gRPC status code for storage version check error

Issue: Incorrect gRPC status code for storage version check error

Problem Description

When executing the WriteStorageObjectsAsync operation and encountering the error "Storage write rejected - version check failed", the Nakama server returns an incorrect gRPC status code.

Current Behavior

When the error "Storage write rejected - version check failed" occurs, the following is returned:

• HTTP status code: 400
• gRPC status code: 3 (INVALID_ARGUMENT)

Expected Behavior

When the error "Storage write rejected - version check failed" occurs, the following should be returned:

• HTTP status code: 400 (or another appropriate code)
• gRPC status code: 9 (FAILED_PRECONDITION)

Rationale

A version check failure is a precondition error, not an invalid argument error. Semantically, this means that the operation cannot be performed due to a state mismatch (object version does not match), which corresponds to the FAILED_PRECONDITION status according to the gRPC specification.

Context

Client code contains a temporary workaround to handle this situation. Due to the incorrect gRPC status code, we are forced to check the error message text against a constant string, as there is no other reliable way to identify this specific error case:

// Remove this once the server is updated to return the correct error code
if (statusCode == 400 && grpcStatusCode == 3 &&
    exception.Message == "Storage write rejected - version check failed.")
{
    // Handle version check error
    // ...
}

This approach is fragile, as it depends on exact message text matching, which may change. This workaround should be removed after the server is fixed.

Steps to Reproduce

1. Execute a storage write operation (WriteStorageObjectsAsync)
2. Attempt to write an object with an incorrect version (version mismatch)
3. Check the returned gRPC status code in the ApiResponseException

Expected Result After Fix

After the server is fixed:

• gRPC status code should be 9 (FAILED_PRECONDITION)
• The workaround in client code can be removed
• Error handling will occur automatically based on the correct status code