mctp: Bump mctp-lib to branch main

[EvanChuchen731]

Why

mctp-lib is pinned to 9e-buildup, which does not carry the
mctp_control module. That module provides the datatypes and the
MctpCodec trait for encoding and decoding DSP0236 control-protocol
messages, so this repo cannot build a control-protocol responder against
the pinned branch.

Branch main also accepts a packet addressed to EID 0, which
9e-buildup dropped whenever this endpoint had another EID. An endpoint
answers on EID 0 until a bus owner assigns it one, so that drop left Set
Endpoint ID unanswerable.

What changes

Branch main alters two APIs this repo calls, and the source changes
here are the call sites those two alterations reach:

• Sender::send_vectored now takes the destination EID ahead of the
  fragmenter. The one production sender and the five test mocks accept
  and ignore it: I2cSender writes to the single peer address fixed at
  construction, and each mock captures or discards every packet.
• Router::inbound now returns Option<AppCookie>, the cookie of the
  handle a matched message was queued for. Server::inbound drops that
  value, since Server::update reaches the message by polling each
  outstanding handle by cookie.

The mctp pin also moves from a floating branch to the rev mctp-lib
main itself pins, so one mctp version resolves for both.

The two lockfiles are regenerated rather than hand-edited: bazel runs
--lockfile_mode=update by default and this repo sets no override, so
editing the crate manifests re-evaluates the rust_crates extension. Both
deltas carry mctp and mctp-lib entries alone.

Testing

• bazel test //services/mctp:mctp_host_tests plus the four pldm host
  tests: 10 of 10 passing
• bazel build --config=k_ast1060_evb //target/ast10x0/...: 405 targets,
  completed successfully
• The clippy aspect over //services/mctp/... and //services/pldm/...:
  no findings
• ./pw format --check over the five edited Rust files and the manifest:
  no changes needed

[rusty1968]

Resolve conflicts.

[rusty1968]

@wmaroneAMD

[EvanChuchen731]

@wmaroneAMD The merge conflicts have been resolved. Please kindly review the changes when you have a moment. Thanks!