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

README.md

@@ -791,8 +791,18 @@ pnpm verify
 
 `pnpm doctor` builds the workspace first, then reports the supported Node.js runtime, installed
 modules and dependency order, schema and migration inventories, the effective PostgreSQL transport
-(TLS) policy, optional read-only PostgreSQL planning, and the current object-storage integration
-state. `.env.example` sets `NODE_ENV=development` deliberately: anything else, including an unset
+(TLS) policy, optional read-only PostgreSQL planning, and the current object-storage and
+outbound-email integration state.
+
+Doctor reads its host infrastructure configuration through the same
+`loadHostConfiguration(process.env)` the API executable uses, so both derive identical settings and
+identical defaults from one deployment environment: configured object storage is reported as
+configured, a module secret the deployment has set is reported as satisfied, and a value neither
+process could accept is reported as a configuration failure rather than silently interpreted one way
+by the diagnostic and another way at startup. An optional service that is genuinely absent — no
+`S3_ENDPOINT`, no `EKKLESIA_SMTP_HOST` — is still a complete deployment and reported as skipped.
+
+`.env.example` sets `NODE_ENV=development` deliberately: anything else, including an unset
 value, is validated as production, and production requires certificate-verified PostgreSQL TLS and
 rejects loopback/`http` identity origins — so the plaintext loopback database this repository's own
 development infrastructure provides is only usable with it set.
@@ -817,7 +827,7 @@ Modules
   ✓ Dependency graph valid
     Dependency order is empty.
   ✓ Permission registry composed
-    5 permissions registered
+    6 permissions registered
   ○ Module lifecycle skipped
     DATABASE_URL is not configured.
   ○ Module configuration skipped
@@ -827,13 +837,14 @@ Data definitions
   ✓ Schemas validated
     0 modules · 0 tables
   ✓ Migrations validated
-    6 migrations · checksums valid
+    7 migrations · checksums valid
     core:0000_identity_core_tables · f8f2086ef06f
     core:0001_authorization_core_tables · 830e1fbc26d0
     core:0002_authorization_integrity · 634294731180
     core:0003_dashboard_navigation_tables · 2cde27807aa4
     core:0004_module_lifecycle_state · c8b5d8b3d48b
     core:0005_module_configuration · c8d57f24f84b
+    core:0006_device_identity · 1db97b7e3ac5
 
 PostgreSQL
   ✓ Database TLS verified
@@ -856,6 +867,10 @@ Object storage
   ✓ No module requires object storage
     0 modules declare a logical storage bucket.
 
+Outbound email
+  ○ Outbound email not configured
+    No EKKLESIA_SMTP_HOST is set. This is a complete deployment: nothing in the platform sends email yet.
+
 Result: READY WITH WARNINGS
 ```