Validate a response payload

Checks a create or patch payload and reports what a real write would do — without writing anything. Never has side effects: no response is created, no pipeline fires, nothing is metered.

Deliberately the same shape as POST /api/v3/surveys/validate: same dual auth, a request discriminated on operation carrying the body the real call would take, and a result of valid, operation and invalid_params with document-relative paths. The value is that the two endpoints behave alike, so a client can validate uniformly. Answers are checked against the survey’s own validation rules, so a payload this endpoint accepts is one the real write accepts.

It reports effects, not just a verdict. When valid is true, effects names the language that would be stamped, the contact and display that would be linked, the quotas that would count, whether the pipeline would fire, and whether the write would be metered. The language is the field that motivated this endpoint: an importer can see that a payload produces language-less responses before writing thousands of them.

Authorization is the same as the operation being validated — read-write for create and patch — so this cannot be used as a cheaper cross-tenant existence probe than the write itself. An inaccessible responseId on a patch validation answers 403, as the patch would.

What it does not do: an endpoint lets a caller check; it cannot stop a caller writing a bad record anyway. Consistency across the write paths comes from all of them calling the same validator — this endpoint is that validator’s public face, not a gate in front of it.