adopt: expose the engine's outbound TLS trust options (upstreamCaFile / upstreamCaPem / upstreamTlsSkipVerify)

[EtaCassiopeia]

Context

Engine PR achird-labs/rift#976 (issue achird-labs/rift#974) landed a process-wide outbound TLS trust policy. Before it, the imposter proxy-stub client used reqwest's compiled-in Mozilla roots and ignored the OS trust store entirely, so recording against an origin issued by a private/corporate CA failed with invalid peer certificate: UnknownIssuer no matter how the host was configured — installing the CA did nothing.

The engine now reads the OS trust store, and accepts three new serve options over the C-ABI:

Option	Type	Meaning
upstreamCaFile	string (path)	Extra CA certificate(s), PEM, appended to the OS trust store
upstreamCaPem	string (PEM)	The same anchor supplied inline. Mutually exclusive with upstreamCaFile — supplying both is a hard error
upstreamTlsSkipVerify	bool	Accept any certificate. Development only; the engine logs a warning

They apply to proxy stub upstreams and to configFile URLs.

Ask (adoption — optional, nothing is broken)

This is not a compatibility break: the options are additive and an SDK that omits them behaves exactly as before. The point is that a user of this SDK currently has no way to reach the capability — they can only get it by driving the engine binary directly.

Expose the three options wherever the SDK builds its serve options today.

Version gating — please read before implementing

ServeOptions is deny_unknown_fields, but that is not a feature-detection mechanism: an engine too old to know these keys silently ignores them rather than rejecting them, because the engine doing the ignoring is the old one. A rejection only ever comes from an engine that already knows the field.

Feature-detect by presence instead. The keys are advertised in:

• rift_build_info().serveOptions (C-ABI), and
• GET /config → serveOptions (admin API).

Absence of upstreamCaPem from that list means an engine too old to support it. Gate on that, and state the minimum engine release in the SDK docs.

Notes

• Prefer surfacing upstreamCaFile/upstreamCaPem as the primary path and upstreamTlsSkipVerify as a clearly-marked development-only escape hatch — that is how the engine's own CLI documents them.
• Worth documenting the SSL_CERT_FILE trap alongside: the engine honours it, but it replaces the trust store rather than appending, so pointing it at a lone private CA silently drops every public root. upstreamCaFile appends, which is why it exists.

Refs: achird-labs/rift#974 (engine issue), achird-labs/rift#976 (engine PR), achird-labs/rift#877 (the serveOptions feature-detection convention).