fix: use sub-message decoding for Error fields (not raw bytes)

The kRPC proto defines error on Response and ProcedureResult as
type Error (a sub-message), not raw bytes. The schema already
declared it that way, so protobufjs was decoding the error as
a nested Error object automatically.

But our client code was treating response.error as if it were
a Uint8Array of raw bytes (matching the wrong type annotation
we had earlier), and we were trying to decode those bytes as
a second Error message. That double-decode was the source of
the "RPC error: .:" with stray substitute character and the
"index out of range" errors when the bytes happened to look
like other protobuf structures.

Fix: use the auto-decoded error object directly. response.error
is now { service, name, description, stackTrace } when set,
and we just read those fields.

This should also let the actual response values decode correctly,
since we were previously mangling the error path.

.commit_msg.txt

@@ -0,0 +1,21 @@
+fix: use sub-message decoding for Error fields (not raw bytes)
+
+The kRPC proto defines error on Response and ProcedureResult as
+type Error (a sub-message), not raw bytes. The schema already
+declared it that way, so protobufjs was decoding the error as
+a nested Error object automatically.
+
+But our client code was treating response.error as if it were
+a Uint8Array of raw bytes (matching the wrong type annotation
+we had earlier), and we were trying to decode those bytes as
+a second Error message. That double-decode was the source of
+the "RPC error: .:" with stray substitute character and the
+"index out of range" errors when the bytes happened to look
+like other protobuf structures.
+
+Fix: use the auto-decoded error object directly. response.error
+is now { service, name, description, stackTrace } when set,
+and we just read those fields.
+
+This should also let the actual response values decode correctly,
+since we were previously mangling the error path.