feat(sdk): add sdk.getRootCa for this server's root CA

[MattDHill]

Adds sdk.getRootCa(effects), returning this server's root CA certificate as PEM.

Why

A service that dials an address the user supplies — a monitor target, a notification endpoint, a webhook — can't resolve a bridge address for it, and users can't see bridge addresses anyway (#3618). So what they paste is whatever StartOS showed them, which on the LAN is always HTTPS with a certificate chaining to this server's root CA. No container trusts that root, so the dial fails verification with SELF_SIGNED_CERT_IN_CHAIN.

Until now the only way to get that root was to mint a certificate you didn't want and take the last link of the chain — and packages doing it by hand have taken the wrong link:

Package	Code	Result
hermes-agent	certs.slice(-1)	correct
openclaw	certs.slice(-1)	correct
dev-env	certs[0]	the leaf — installed as a trust anchor, trusts nothing, raises no error

One in three wrong, on a call whose failure is invisible. That is the whole argument for this change.

Implementation note

Built over getSslCertificate rather than as a new OS effect, so it works on shipping StartOS instead of gating every caller on the next release. The pretext hostname is the OS bridge IP — the one hostname admitted by the allowlist's compiled-in HOST_IP subnet check (net/ssl.rs) rather than by whatever the gateway table currently holds, which is what admits 127.0.0.1.

If the OS later exposes the root directly, only GetRootCa.fetch changes; the SDK surface is already right and no package needs touching.

It returns a Watchable to match the other readers, not to fix a reactivity problem — the root is minted once at setup (AccountInfo::new, setup.rs) with a ten-year life and there is no rotation flow, so in practice it never changes.

Changes

• shared-libs/ts-modules/start-core/lib/util/GetRootCa.ts — new Watchable<string>
• projects/start-sdk/lib/StartSdk.ts — sdk.getRootCa
• docs/src/service-to-service.md — new "Trusting this server's certificates" section, with the "don't index getSslCertificate" warning and the rootfs-not-volume placement rule
• docs/src/recipes.md, CHANGELOG.md (2.0.10, unreleased)

Verified

• tsc clean in shared-libs/ts-modules/start-core and projects/start-sdk (the latter built against this branch's start-core dist, not the installed one)
• start-core TS suite: 86 passed, 9 skipped
• prettier --check clean on every changed file

Not exercised against a running service — the SDK surface is a thin wrapper over an effect that already works, but the trust install itself is verified end-to-end in the consumer PR below.

Follow-on

• Start9Labs/uptime-kuma-startos#12 is the first consumer; it currently hand-rolls this and can collapse to sdk.getRootCa.
• #3618 is the underlying gap — if internal addresses become visible in the UI, most callers won't need this at all.

[dr-bonez]

Expires in 10 years... Do we really need to make it watchable?

[MattDHill]

No — dropped it. It's a plain Promise<string> now, same as getOsIp: minted once at setup, ten-year life, no rotation flow, so there's nothing to subscribe to.

[dr-bonez]

Can this be an empty array? Might be nice to not have to make 2 separate rpc calls

[MattDHill]

Yes, and it now is — one RPC instead of two. The validation loop has nothing to check, and cert_for mints the discarded leaf with SANInfo::new over an empty set; make_leaf_cert already falls back to CN=localhost with no DNS name, and an empty SubjectAlternativeName builds fine on openssl 0.10.80 (I compiled a throwaway crate against the pinned version to be sure — the modern stack-based build encodes an empty GENERAL_NAMES rather than choking on an empty config string, which is what would have failed on older rust-openssl).

Nice side effect: the leaf it leaves behind is now inert rather than a plausible-looking certificate for the OS's own bridge address.