v0.6.1 — the WebRTC message-size check stops being inert

0.6.0 added a connect-time check that refuses a transport too small to carry a rite's frames. On the WebRTC path it did nothing: the adapter reported 0 — "unknown" — because WebRtcChannel did not expose the SCTP association's figure. CupriWebRTC 0.4.0 exposes it, so the adapter now reports a real number and the check applies.

What changed

CupriWebRTC reference	0.3.1 → 0.4.0
WebRtcDataChannel.MaxMessageBytes	0 → the channel's effective figure
CupriWebRtcTransport(…)	new optional peerMaxMessageBytes

Read the number as "what we will send", not "what the pair agreed"

The peer's half is an SDP attribute, and this path has no signalling by design — a browser synthesises its answer from the published static parameters, so its offer never reaches the node. There is usually nobody to supply peerMaxMessageBytes from; set it only when you know the peers you serve are limited (a stack or middlebox at the 64 KiB interoperable floor). Unset, this stack's own 256 KiB stands, which is what every measured pairing agrees to.

So a browser that negotiated below the rites' requirement is still not caught on the .NET side. It is caught at the browser end, which can read pc.sctp.maxMessageSize. Between the two ends the case is covered; neither covers it alone.

That limitation is stated on the adapter, on the transport parameter, and in transports-and-limits.md rather than left implicit — a check that appears to prove more than it does is worse than no check.

One asymmetry worth knowing

A peer's advertised figure caps what this endpoint sends it, and never what it accepts. The receive limit was published in the endpoint's static parameters before any peer arrived, so one peer's low advertisement must not retroactively narrow the promise every other peer read. That is CupriWebRTC's decision and it is the right one.

Also

IDataChannel.MaxMessageBytes previously said "as negotiated with the peer" — too strong for an interface an implementation may satisfy with no negotiation at all. It now asks for the most a transport can honestly promise, with 0 for unknown.

466 unit tests green. No API break; additive only.