fix: the cipher policy an integrator sets does not bind the connection that is negotiated

[DavidCozens]

docs/tls.md requires a TLS Stream to pass the integrator's cipher policy
through unchanged where the underlying library allows one to be selected, pinning
none of its own. RFC 5425 §4.2.3 is the requirement behind it: syslog
applications SHOULD permit administrators to select the cryptographic level as a
matter of local policy.

Neither adapter delivers that on the connection that actually gets negotiated.

OpenSSL — the setting binds TLS 1.2 and below only

SolidSyslogOpenSslStream.c sets a floor with no ceiling:

SSL_CTX_set_min_proto_version(ctx, TLS1_2_VERSION)

and configures ciphers through one call:

SSL_CTX_set_cipher_list(ctx, cipherList)

SSL_CTX_set_ciphersuites is never called anywhere in the pack. Since OpenSSL
1.1.1 those are two separate lists: set_cipher_list governs TLS 1.2 and below,
while TLS 1.3 ciphersuites have their own list and their own defaults. Against an
OpenSSL 3.0 peer, TLS 1.3 is what gets negotiated — so in the common case the
caller's CipherList has no effect on the cipher in use, and nothing says so.

The field's own documentation is accurate: "TLS 1.2 cipher list". What is
missing is the consequence, and the means to express a policy for TLS 1.3.

Mbed TLS — no cipher configuration at all

SolidSyslogMbedTlsStreamConfig has no cipher or ciphersuite field, and
SolidSyslogMbedTlsStream.c calls no ciphersuite API. The preset's defaults
apply and the integrator has no way to express a policy.

What the fix might be

Three routes, and this issue does not pick one:

1. Expose a ciphersuite setting alongside the existing list, so a policy can be
   stated for the version actually negotiated.
2. Pin a ceiling as well as a floor, which makes the existing list bind again —
   at the cost of refusing a better protocol version.
3. Decide the obligation is met by the library's own defaults, which for TLS 1.3
   are all AEAD with forward secrecy, and say so on the contract page instead.

Route 3 is a documentation change rather than a code one, and would mean amending
docs/tls.md. It should not be chosen by default just because it is cheapest.

Acceptance

• An integrator can express a cipher policy that binds the connection that is
  negotiated, or the contract states plainly that they cannot and why
• Both TLS adapters reach the same answer
• The divergence notes come off both platform pages

[DavidCozens]

RFC 9662 removes one of the three routes

Route 2 — pin a protocol ceiling so the existing cipher list binds the negotiated
connection — is not available.

RFC 9662, Updates to the Cipher Suites in Secure Syslog, is Standards Track and
updates RFC 5425. §4.2:

Implementations of [RFC5425] SHOULD support TLS 1.3 [RFC8446] and, if
implemented, MUST prefer to negotiate TLS 1.3 over earlier versions of TLS.

Pinning a ceiling at TLS 1.2 to make SSL_CTX_set_cipher_list bite would breach
that preference requirement. BCP 195 §3.1.1, which RFC 9662 normatively
references, says the same for TLS generally.

So the live options are:

1. Expose a ciphersuite setting alongside the existing list, so a policy can
   be stated for the version actually negotiated.
2. Defer to the library's own TLS 1.3 defaults and say so on the contract
   page instead of implying a policy can be expressed.

RFC 9662 also gives option 2 more support than it had. §4.2 asks that
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 be offered, and the TLS 1.3 defaults in
both shipped backends are AEAD suites with forward secrecy — which is the
property RFC 9662 downgraded the 2009 mandatory suite for lacking.

Both floor sites now carry a comment saying no ceiling is set and why, so this
does not get closed by accident while fixing something else.