Split config protobuf from mesh protocol types

[i386]

Summary

• move config sync messages into a new mesh-llm/proto/config.proto
• keep mesh control-plane protobuf types in node.proto and expose them through crate::proto::mesh
• update protocol, mesh, inventory, and test code to use the split generated modules
• refresh protocol and testing docs to describe separate mesh and config protobuf schemas

Testing

• just build

[Copilot]

Copilot encountered an error and was unable to review this pull request. You can try again by re-requesting a review.

[ndizazzo]

There's some stuff in #278 that I was hoping we'd get with this work that will set up and unlock some things down the road in the config protocol, like command execution so that I can trigger model refreshes. Would you mind taking a look at the capability diff from the issue and this PR. It also has words for owner attestation built in, which I think is important:

Capability	Implemented?
Split config protobuf messages into proto/config.proto	Partial match — aligns with the spec’s direction of separating config concerns, but only at the schema level
Separate generated protobuf modules for mesh vs config (crate::proto::mesh / crate::proto::config)	Partial match — useful groundwork, not the separate communication channel the spec asks for
Keep mesh-state protobufs in node.proto	Partial match — organizationally aligned, but not transport isolation
Update code to use split mesh/config protobuf namespaces	Partial match — mechanical refactor supporting future separation
Update docs to describe split mesh/config protobuf schemas	Partial match — documentation alignment only
Document config streams 0x0b / 0x0c in protocol docs	Partial match — clarifies existing behavior, but does not create a new channel
Create a separate QUIC endpoint for owner-control traffic	No match — not implemented
Introduce a distinct ALPN like mesh-llm-control/1	No match — still uses mesh-llm/1
Isolate config traffic from the existing public mesh control plane	No match — config still rides the shared control plane via existing stream types
Add a direct owner-attestation handshake at connection setup	No match — current auth still depends on existing peer/gossip-derived owner state
Create a truly separate private owner-control plane	No match — this is the main missing requirement
Add a dedicated remote inventory refresh command on the new control path	No match — not implemented
Preserve protobuf-based config messages	Match — consistent with the spec’s proposed protobuf-only owner-control direction
Preserve config get/watch/apply message family semantics	Partial match — messages still exist, but they were reorganized rather than moved to a new isolated plane
Improve protocol/schema organization beyond what the spec strictly requires	Extra capability — helpful refactor, but not part of the spec’s core acceptance bar
Rename/repartition internal proto API surface for clearer ownership (mesh vs config)	Extra capability — internal cleanliness benefit not explicitly required by the spec
Refresh tests to use the split proto modules	Extra capability — maintenance benefit not central to the spec

[i386]

@ndizazzo will come back to this after I sort out new hf crate