fix: give Doctor the host configuration the runtime receives

`pnpm doctor` and `startApi` each read their own subset of the same
environment variables, and the subsets had drifted. Doctor never read
`S3_*` or module secrets at all, so a correctly configured installation
was told its object storage was "not configured" and every module
requiring a bucket or a secret was reported blocked -- while the runtime,
from the identical environment, bound those buckets and ran the modules.

Both executables now map the environment through one
`loadHostConfiguration(env)` in Core, which takes the environment as an
argument and never reads `process.env` itself. Validation stays with the
existing per-domain validators, so each caller keeps its own failure
behaviour: startup refuses a rejected value, Doctor reports it as a
sanitized code.

Doctor's storage option becomes raw input like its mail option, so a
half-configured provider is reported as a blocking configuration failure
instead of throwing before a report exists. The outbound-email check --
computed, counted toward the result, but absent from every rendered
section -- is now printed, and the rendered set is asserted against a
real report so a future check cannot go missing the same way.

Co-Authored-By: Claude Opus 5 <[email protected]>

apps/api/src/config.ts

@@ -90,7 +90,7 @@ export interface ApiRuntimeConfig {
 export interface ApiRuntimeConfigInput {
   /** Optional. Defaults to direct mode (trusts only the actual immediate socket peer) — no proxy
    * trust unless explicitly configured. See `./client-address.js`. */
-  readonly clientAddress?: ClientAddressConfigInput;
+  readonly clientAddress?: ClientAddressConfigInput | undefined;
   readonly databaseUrl?: unknown;
   /** Optional. Defaults to certificate-verified TLS in production and plaintext in development;
    * production can never select plaintext. See `@ekklesia/core/database`'s transport policy. */