Preserve safe validation diagnostics during app-config extraction #457

Description

Runtime app-config extraction discards every validator error code and message, keeping only the first field path. Downstream applications cannot tell an operator which safe semantic condition failed, even when their validator supplies a fixed, value-free diagnostic.

This hid a reproducible Auctioneer configuration/build mismatch: a policy selects a feature-gated bidder implementation, but the serving WASM was built without its required Cargo feature. The same policy validates with that feature enabled. The operator receives only a generic validation failure.

The current redaction protects resolved secrets and must remain the default. Printing an entire validator::ValidationErrors, its parameters, or arbitrary custom messages is not a safe fix.

Steps to reproduce

1. Implement a typed app-config validator that returns an error for a build/config mismatch, with a fixed code such as implementation_unavailable and a safe explanation derived from compiled metadata.
2. Publish a valid envelope that triggers that validator.
3. Extract it through AppConfig::<C>::from_store.
4. Observe that the failure retains the field path but loses the code and explanation. The downstream error can report only a generic validation failure at that path.

Downstream verification used two local Viceroy runs with the same policy: the default guest rejected it, while the feature-enabled guest loaded it and exposed the selected implementation. No hosted-provider reproduction is claimed.

Verified source

• Auctioneer's pinned SDK revision: extractor validation mapping at 598f0a2. It constructs StoreExtractionReason::Validation with a generic message and the first field path.
• Current main: validation mapping at cf2c57b. This path uses ConfigOutOfDate, but also deliberately drops formatted validator details and retains only the first field path.
• Downstream context: IABTechLab/auctioneer#160. Auctioneer also needs to preserve its own safe semantic reason before invoking the SDK; that application fix is separate.

Expected behavior

Provide an explicit, bounded way for applications to preserve trusted validation diagnostics for operator logging. A missing compiled implementation should explain the required build feature and the need to rebuild both the CLI and serving guest when that information comes from compiled declarations.

Keep unauthenticated HTTP error responses coarse by default. Do not infer that arbitrary validator messages or parameter maps are safe merely because an application supplied them.

Done when

• A supported structured/opt-in contract carries a safe validation code, sanitized structural path, and approved operator-facing explanation through runtime extraction.
• Existing generic behavior remains the fallback for unapproved or unknown diagnostics.
• Resolved secret values, rejected URLs, validator parameter values, and attacker-controlled map keys do not enter logs or public responses.
• Diagnostic size/count limits are explicit; extraction byte/depth/node limits, deadline behavior, and fail-closed semantics are unchanged.
• The fix does not add a second config-store read or reparse the complete policy to recover an error reason.
• Tests cover a safe semantic refusal, its feature-enabled success control, ordinary structural validation, nested paths, secret/value canaries, and untrusted custom messages.
• Shared core behavior and the CLI/runtime diagnostic relationship are documented and exercised across the affected adapter contracts.

Affected area: Core (extractors); CLI typed-config diagnostics.