feat(rust): @framing selector for a protocol's connect/serve helpers

[Kinflou]

What

Makes wire framing reachable from a schema. A protocol declares it with an annotation:

@framing = "jsonrpc"
protocol Rpc {
    function now() -> u32;
}

The Rust generator reads @framing off the frozen Protocol.parameters and, for a non-datagram pick, emits the JSON-RPC stack instead of the hard-wired datagram one:

generated item	datagram (default, unchanged)	@framing = "jsonrpc"
<Proto>Client newtype	Client<T, W>	Client<T, W, comline_runtime::framing::JsonRpcFraming>
connect()	Client::connect(..)	Client::connect_with_framing(.., framing, ..)
<Proto>Dispatcher::serve()	Server::new(..)	Server::with_framing(.., framing)
Handshake framing field	FRAMING_DATAGRAM	framing.name()
contract imports	as before	+ Framing, - FRAMING_DATAGRAM when no protocol in the file needs it

Recognised values: jsonrpc, json-rpc, jsonrpc-2.0. Anything absent or unrecognised keeps the datagram default byte-for-byte — the conformance goldens don't move.

Why

The handshake, Framing trait, JsonRpcFraming impl, and *_with_framing constructors all already exist in the runtime; nothing selected them. This is the last piece: a schema-level switch so the generated connect / serve helpers aren't pinned to datagram.

No RUNTIME_REV bump — the runtime side is already landed.

Tests

• generate.rs::framing_annotation_selects_jsonrpc_for_the_connect_and_serve_helpers — string-checks the emitted JSON-RPC stack and the absence of the datagram path.
• compiles.rs — a second schema carrying a @framing = "jsonrpc" protocol is generated and cargo build-ed against the real comline-runtime next to the datagram one.
• Existing code_mode_generates_enum_and_protocol (asserts the exact datagram imports + Server::new + Client::connect) still passes unchanged.

[Kinflou]

Framing should likely be at a project's settings level such as comline.toml, this is just for testing