0.10: Add opt-in startup schema validation

[bazer]

Objective

Add opt-in startup schema validation for hosted applications by adapting DataLinq's existing provider metadata readers, schema comparer, structured differences, and diagnostics to one explicit host policy.

Required scope

• Expose a structured runtime validation service over registered database targets.
• Add explicit fail-fast, warning-only, and disabled policies.
• Reuse the current provider metadata and schema-comparison model; do not create a competing representation.
• Propagate cancellation and timeout through provider metadata reads using the A10 contract.
• Distinguish missing secrets, connectivity failure, metadata-read failure, schema drift, unsupported differences, timeout, and cancellation.
• Validate multiple registered targets in deterministic order with a defined aggregation policy.
• Emit structured host logging without connection strings, credentials, or other secrets.
• Integrate startup ownership and disposal through H10.

Acceptance criteria

• Fail-fast policy prevents startup on actionable drift and exposes the structured differences.
• Warning-only policy reports the same semantic result and allows startup to continue.
• Disabled policy performs no database access.
• Multiple-target ordering and partial-failure aggregation are deterministic and covered by tests.
• Cancellation, timeout, connectivity, missing-secret, metadata-read, and unsupported-difference outcomes remain distinguishable.
• Validation never generates, applies, or repairs a migration.
• ASP.NET Core and Generic Host fixtures cover startup behavior and secret-redacted logging.
• Focused V10 evidence is recorded in 0.10: Produce release evidence and frozen-candidate closeout #106 before this issue closes.

Dependency and order

• Depends on 0.10: Implement native async and cancellation #107 for async/cancellation semantics and 0.10: Add DI, hosting, and explicit unit-of-work support #108 for host lifetime/policy integration.
• Uses existing schema readers/comparer as authority; implementation stops if a competing schema model appears necessary.

Explicit non-goals

• Schema repair or migration generation/application.
• MSBuild/build-time validation or source-generator database access.
• Interactive secret prompting during non-interactive startup.
• Named/keyed target registration beyond the accepted H10 baseline.

Planning sources

• 0.10 V10 roadmap contract
• Implementation order W5
• Durable schema-validation design plan