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/architecture/platform-architecture.md

@@ -508,6 +508,17 @@ something real needs one, and nothing does. Email is optional: an installation w
 complete deployment, and Better Auth's verification and reset hooks remain unimplemented until
 Pass 2.
 
+Phase 7C pass 1B makes host infrastructure configuration a single shared mapping. Every executable —
+`apps/api`, `pnpm doctor`, and the migration and owner-bootstrap commands — turns its environment
+into typed inputs through one `loadHostConfiguration(env)` in Core, which takes the environment **as
+an argument** and never reads `process.env` itself, exactly as the module secret source does.
+Validation stays with the existing per-domain validators, so each caller keeps its own failure
+behaviour: `startApi` refuses to start on a rejected value, while Doctor reports it as a sanitized
+code. This replaced two executables that each read their own subset of the same variables and had
+drifted — Doctor never read `S3_*` or module secrets at all, so it reported a correctly configured
+installation as having neither, and reported modules blocked that the runtime was running. A
+diagnostic that disagrees with the runtime it diagnoses is worse than no diagnostic.
+
 The two browser roles share the existing `defineModuleUi({ id, version, mount })` export and exactly
 the same `ModuleUiHostContext`; role selection comes from separate artifacts, never a `mode`,
 `presentation.kind`, or host-identity branch. The canonical builder reads only