chore: Refactor ConversionError

[sergerad]

Context

Closes #1528.

ConversionError is currently factored as an enum whose variants are never matched on.

We also wish to add proto field paths to error contents when proto types are being converted to domain types, producing messages like "header.account_root: value is not in range 0..MODULUS".

Changes

• Refactored ConversionError from a public enum to an opaque struct with a field path stack and a boxed error source. The Display impl renders dotted paths like header.account_root: value is not in range 0..MODULUS.
• Added ConversionResultExt trait on Result<T, E: Into<ConversionError>> to ergonomically inject field context via .context("field_name") at each ? site.
• Added TryConvertFieldExt trait on Option<T> that combines ok_or(missing_field) + try_into() + .context() into a single .try_convert_field::<ParentProtoMessage>("field_name")? call, eliminating the most common three-line boilerplate pattern.
• Added impl_from_for_conversion_error! macro to replace 13 identical From<ExternalError> for ConversionError implementations.
• Wired .context() calls through all proto-to-domain conversions in crates/proto/src/domain/ (account, block, batch, note, nullifier, merkle, transaction, mempool, digest).
• Wired .context() through downstream crates: store/src/server/, block-producer/src/store/, ntx-builder/src/clients/store.rs.
• Fixed incorrect missing_field type parameters (e.g. missing_field::<FeeParameters>("fee_parameters") → missing_field::<BlockHeader>("fee_parameters") where fee_parameters is a field on BlockHeader).
• Made read_account_id generic over the parent proto message type so missing_field errors correctly identify the containing message.
• Replaced all stringify!(field_name) with "field_name" string literals in missing_field calls.
• Re-exported prost from miden-node-proto for downstream use of the prost::Message trait bound.
• Added unit tests for ConversionResultExt (single field, nested paths, deep nesting, external error types) and TryConvertFieldExt (missing field, conversion error).

[Mirko-von-Leipzig]

Top level overview; attaching to an arbitrary file so we can discuss inline.

I think this gives the correct end result, but I worry about the ergonomics of it. Having to specify the field, type and operation is a problem and will be error prone. I'll leaving some thoughts on possible things to explore.

At a higher level, I want to move away from TryFrom for something this specific. We really should use a dedicated GrpcDecode trait. This would be a rather large diff so I would suggest we do this in tandem with #1742. This allows us to have the current implementation, where we can then slowly move over to the #1742 piece by piece without requiring all things to change at once. So as we implement a method for #1742, we also implement the GrpcDecode parts that we need.

[Mirko-von-Leipzig]

serde solves the redundancy of specifying the parent type (proto::blockchain::BlockHeader) by having dedicated sub-decoders. Something like this (I forget the exact details):

/// This gives a single place to inject the parent struct name.
struct GrpcStructDecoder<T: GrpcMessage>;

impl GrpcStructDecoder<T: GrpcMessage> {
    fn decode_field<U: GrpcDecode, V>(name: &'static str, value: U) -> Result<V> {
        value.decode().context(name)?
    }
}

let mut decoder = value.decode_struct();
let account_root = decoder.decode_field("account_root", value.account_root)?;

and they have similar helper structs for arrays (which inject indices), and enums etc.

This still requires manually specifying the field name which is a bummer, but I wonder if we can't write a proc-macro that injects that intelligently for us to give something along

#[GrpcDecode::struct]
impl GrpcDecode<BlockHeader> for proto::blockchain::BlockHeader {
    fn decode(self) -> Result<BlockHeader, GrpcDecodeError> {
        let prev_block_commitment = self.prev_block_commitment.decode()?;
        let chain_commitment = self.chain_commitment.decode()?;
        let account_root = self.account_root.decode()?;
        let nullifier_root = self.nullifier_root.decode()?;

        ...
        Ok(BlockHeader::new(...))
    }
}

[Mirko-von-Leipzig]

Maybe we can add a decode_required() which the proc macro can fill in appropriately?

[Mirko-von-Leipzig]

Since this occurs a lot, I wonder if we can't add our own extension trait that does this more trivially somehow. e.g. Vec<u8>::decode_bytes for gRPC specially.