fix: four Create functions accept a configuration they cannot work without, and report nothing

[DavidCozens]

Scope note, 2026-08-17. Retitled from "neither TLS stream". The comment below
extends this to SolidSyslogLwipRawTcpStream_Create and
SolidSyslogLwipRawDnsResolver_Create, so the issue covers four classes across
two platform packs, and the fix is one decision about what Create owes the
caller across all four. The sections below describe the two TLS adapters only;
read them with the comment.

docs/tls.md requires a TLS Stream given an unusable configuration to report a
bad configuration and return the Null object, rather than accepting it and
failing later. Neither adapter does this.

What happens today

Create in both adapters takes a pool slot, copies the config, and validates
nothing:

• Sleep is documented "required — there is no fallback" in both headers, and
  both call self->Config.Sleep(...) unguarded on the first WANT_READ /
  WANT_WRITE poll. That is every real handshake, so a NULL Sleep is a NULL
  function-pointer call on the first connection attempt.
• SolidSyslogMbedTlsStream additionally passes Rng and CaChain straight to
  mbedtls_ssl_conf_rng and mbedtls_ssl_conf_ca_chain, neither of which
  returns a status. A NULL there surfaces later as a handshake failure rather
  than as the configuration error it is.

No test covers a NULL in any of these fields; every test in both suites wires
them.

Why this is not a new rule

The library already holds Create to this contract elsewhere.
SolidSyslogMetaSd_Create reports NULL_CONFIG and NULL_COUNTER as WARNING
and returns the Null structured data rather than proceeding. The TLS adapters are
not following a rule the codebase already demonstrates.

Acceptance

• A NULL Sleep is reported at Create and the Null stream returned, in both
  adapters
• SolidSyslogMbedTlsStream does the same for a NULL Rng and a NULL CaChain
• Severity follows docs/error-severity.md — a Create that falls back to the
  Null object cannot deliver, which is the CRITICAL case
• Tests cover each field's NULL, since none do today

Not in scope

Whether other classes share the lapse. This was found in the two TLS adapters
while writing their contract; a sweep across every Create is separate work.

[DavidCozens]

The lwIP TCP stream and DNS resolver do the same thing

Found during the lwIP documentation triage (#744), 2026-08-10.

SolidSyslogLwipRawTcpStream_Create and SolidSyslogLwipRawDnsResolver_Create
both open with handle = SolidSyslogNull…_Get() and only proceed
if (IsValidConfig(config)), where valid means a non-NULL config carrying a
non-NULL Sleep. Neither reports anything on that path — the only Report
calls in either translation unit are pool exhaustion and unknown-destroy.

So wiring either without a Sleep returns a working-looking handle that
silently delivers nothing, and nothing tells the integrator. Both need one: the
TCP stream's synchronous Open sleeps while tcp_connect completes, and the
DNS resolver sleeps through its bounded query spin.

That is the same shape as this issue's TLS finding, and the same departure from
the bad-setup contract — a Create that falls back to the nil object reports it.
Adding it here rather than raising a fourth issue, since the fix is one decision
about what Create owes the caller across all four classes.

Documented on the lwIP platform page meanwhile, so the behaviour is at least
visible: 'Create it without one and you get the shared Null object back, with
nothing reported.'