worker ceal call: client-side validation_error is opaque — name the rejected operand and point to input-contract discovery #9

Structural pattern: an agent-first CLI that rejects a call client-side with a generic validation_error (no receipt, no offending-operand name, no discovery pointer) trains callers to retry blind variants instead of correcting the one wrong operand.

Triggering instance(s): packages/ceal-worker-cli/src/index.ts — writeCallValidationFailure → writeCallUnavailable("validation_error", io, null, null) renders only 'The capability call could not be completed.' It fires for unknown options (e.g. --json), malformed key=value operands, and duplicate keys alike. Observed during goal4 P5 / goal5 S6 (2026-08-05): repeated message.search failures via gateway_issued_client_session were diagnosed as exactly this — call-grammar misuse never reaching the Gateway, while the same session and capability succeeded live once the published contract (required: [query, fields], discoverable via ceal capabilities --detail) was followed.

Impact bound: no runtime defect; capability and session healthy. Cost is agent iteration waste and misdiagnosis pressure (looked like a 0.73.0 regression; wasn't — fields requirement dates to 2026-07-25 input.v2).

Fix sketch: (1) name the rejected operand/option in the error message; (2) set next_action to ceal capabilities --detail for input-contract discovery (Gateway-side invalid_arguments next_action deserves the same pointer, in corca-ai/ceal); (3) keep the error kind stable.

Destination: corca-ai/ceal-cli (worker CLI source authority).