feat(server): fail-fast configuration validation on boot

[FelixTJDietrich]

Priority

P0 — public 1.0 gate. Part of #1378 and a server-side dependency of #1547.

Problem

Known production misconfiguration still risks surfacing as late runtime failures or one-error-at-a-time startup attempts. A stranger needs one complete, redacted diagnosis, and the readiness UI needs stable facts without exposing raw configuration.

Scope

• In the production profile, aggregate every applicable missing/invalid required setting before refusing startup.
• Cover at least credential-encryption key, webhook secrets, database, NATS and runtime-role consistency, external base URL, login/provider configuration needed by the active role, LLM configuration, and agent image/runtime contract.
• Distinguish required, recommended, optional, and not-applicable-by-role checks.
• Each diagnostic has a stable identifier, configuration key or capability name, affected role, human explanation, and exact documentation link.
• Never include a secret value, length/hash useful for fingerprinting, connection string, token, or raw exception/configuration object.
• Dev/test profiles remain deliberately usable; exemptions are explicit and tested rather than broad validation disablement.
• Where the process can safely run, expose the same redacted readiness facts through an admin-authorized API consumed by feat(server,webapp): guide the first operator from installation to a safe shadow run #1547. Do not create a second validation implementation in the webapp.

Done when

• A fixture with several independent defects reports all applicable defects in one startup attempt.
• Every supported runtime role has positive, negative, and not-applicable tests.
• Planted credentials/config values cannot appear in startup output or the readiness DTO.
• A check cannot silently discover zero expected configuration/source inputs and report success.
• Documentation links are stable and validated by the docs link checker.
• feat(server,webapp): guide the first operator from installation to a safe shadow run #1547 can consume structured facts while startup remains the authority for boot-fatal requirements.

Non-goals

• Raw Actuator environment/configprops, Spring bean/property-source browsing, arbitrary deployment topology validation, or automatically repairing configuration.

[FelixTJDietrich]

Partial coverage landed with #1400: an unsupported HEPHAESTUS_LLM_DISPLAY_CURRENCY now fails startup naming what is accepted, and a boot guard rejects a non-digest agent-pi image. The pattern is established — this issue remains for the rest of the required-configuration surface (webhook secret length, credential-encryption key, NATS flags, database, external base URL), aggregated into one startup error rather than fail-on-first.

[FelixTJDietrich]

Coverage list needs updating after #1400: LLM provider configuration is now DB-backed (agent/catalog), so it is no longer a startup-validation target. Validate instead: credential-encryption key, webhook secret length, NATS enablement flags, database, external base URL, and the LLM proxy settings. Confirmed still true: no aggregated startup validator exists — only WorkspaceProperties' local @Validated.