fix(ipc): decode explicit null results and stop silent null degradation

[cyberspace-cs]

Summary

Fixes a silent-failure channel in the IPC protocol where JSON null
was treated as "field absent" instead of a legal value.

1. Decoder: explicit null results were rejected as ambiguous

ResponseFrame::deserialize and the Frame visitor modelled the
result field as Option<Value>. serde collapses JSON "result": null
into the same None as a missing field, so a reply like
{"id":"x","result":null} was rejected with a misleading
ambiguous response: expected exactly one of result or error.

That shape is not hypothetical: the daemon emits it through
serde_json::to_value(..).unwrap_or(Value::Null) (see below), and
Value::Null serialises back to "result": null — so the encoder and
decoder were asymmetric.

Both deserializers now parse the raw value
(#[serde(default, deserialize_with)]) so an explicit null result
decodes to Ok(Value::Null) while a missing field stays an error.

2. Daemon: result serialisation failures silently degraded to null

Every serde_json::to_value(..).unwrap_or(Value::Null) site silently
turned a result serialisation failure — e.g. a payload nested deeper
than serde_json's 128-level recursion limit — into a JSON null
result, hiding the real failure from the CLI client and colliding with
legitimate null results.

All of these now route through ok_value() / serialise_err()
helpers that return a structured protocol_error with the underlying
serde message. The upload/download param-staging paths (which
forwarded null params to the extension on failure) now return the
same error instead.

Testing

• cargo test -p bsk-protocol — 158 passed (4 new: explicit-null
  decode for Frame and ResponseFrame, serialise round-trip
  symmetry, missing-field regression)
• cargo test -p bsk --lib — 328 passed, 2 failed (both pre-existing
  environment failures in skill_install::harness on hosts with a real
  hermes install; unrelated to this change)
• cargo fmt clean on both crates