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]>

docs/module-development/README.md

@@ -1133,12 +1133,18 @@ by the process such a module takes down.
 and reachable, and `object-storage.bindings` lists which modules require storage and where each
 logical bucket is bound. Neither prints a credential. A module requiring storage on an installation
 with none configured makes the bindings check fail with a remediation line; a provider that is merely
-unreachable is a warning, because modules already running are unaffected.
+unreachable is a warning, because modules already running are unaffected. A provider whose settings
+are structurally invalid is a blocking failure, reported as a sanitized code — the runtime refuses to
+start on the same input.
 
 `pnpm doctor`'s `modules.configuration` check reports whether each installed module's configuration
 would let it run, naming the offending key when it would not. It prints **no configuration values** —
 secret or otherwise — only counts, keys, and reasons.
 
+Both checks evaluate the same host configuration the runtime receives: Doctor and the API executable
+map one deployment environment through the same loader, so a bucket the platform would bind is never
+reported unbound, and a module secret the deployment has set is never reported missing.
+
 `pnpm doctor` builds first and presents the same production discovery results as a concise,
 read-only dashboard. It lists discovered module IDs and versions in dependency order, reports
 schema and migration counts, and shows safe migration identities with truncated checksums. Schema