[Epic] Config validation: accepted-then-brick values

Configuration and schema values that pass validation at write time and then prove fatal later — the "accepted-then-brick" class.

## Scope

**In:** the gap between the shallow type/range check a value passes when it is set, and the native constructor, worker resource limit, or schema-apply step that later rejects it fatally. Also the propagation question: whether a value should be validated before it is replicated to peers.

**Out:** validation of *well-formed* config that is merely undesirable, and the config-file parsing/merging path (which lives with the env-var work in harper#1676) — this epic is specifically about values that are accepted and then kill the process.

## Why this is a class and not four bugs

Every member has the same shape: a value clears a `Joi` check with no upper bound or no coverage at all, gets persisted, and then aborts the process at a point where nothing can reject it any more — usually at boot, where there is no request to fail and no operator watching. The severity difference between members is entirely blast radius, not mechanism: a single-node brick when the value is local, a whole-cluster brick when `replicated: true` fans the same landmine to every peer before any of them restart, which removes the surviving-peer recovery path.

The fix is plausibly one piece of work — validate deeply at the boundary that accepts the value, and validate before propagation rather than after — which is the argument for tracking them together.

_Created during backlog triage. Child issues keep their own priorities and milestones._

Start by tracing the configuration write boundary and its Joi checks, then follow persistence, replication, and the later native-constructor, worker-resource, or schema-apply consumers described in the epic. Done means fatal values are rejected deeply before persistence and before propagation to peers, with the relevant child cases covered.

Written by the indexing model from the issue text.