Set the workspace message-action policy

Request body for setting a workspace's message-action policy (admin only, full replace).

EVERY POLICY FIELD IS REQUIRED, AND THAT IS THE WHOLE DESIGN OF THIS CLASS. It carries no defaults for any field it can STORE, which is what makes it impossible for this body and :class:MessageActionPolicy to declare two different defaults for the same field. (The two GET echoes below do default to None — they are accepted so a GET response round-trips, excluded from every dump, and never stored, so neither is a second declaration of a policy value that could drift.) There is exactly one set of field defaults for the policy in this module — the policy's own — and it answers exactly one question: what a workspace that has NEVER been configured gets. The read path's :data:_ABSENT_KEY_FALLBACKS is not a second set: it narrows a STORED block that omits a key, where absence is missing information with nobody left to ask. Absence in a REQUEST is different — the caller is present to be told — so "what if they left it out" is not a defaults question at all; it is a malformed request.

It was not always so, and the failure that changed it is worth keeping. Every field used to carry its own default, which meant the same field was declared twice with two independent values, and they drifted: proactive_reactions_enabled was True on the policy (shipped 2026-08-03) and False here, so a PUT that omitted it silently disabled the capability that had just shipped, answered 200, and published default: false in the OpenAPI contract as if that were correct. The console had already diagnosed this from the outside and worked around it client-side (useMessageActionPolicy.ts's Required<…> guard, whose comment called a partial body "silent data loss" until the hole closed); the hole itself was server-side and stayed open.

Syncing the two sets of defaults was the obvious repair and is the wrong one: it only changes WHICH silent thing an omission does. With them synced, omitting proactive_replies_enabled would GRANT unprompted replies — text that cannot be taken back — to a workspace that had turned them off. The same argument, about the allowlist, was already written in this file before this change: defaulting it to empty "would make the same partial body silently disable every reaction instead, trading one surprise for a worse one."

So the second set of defaults is deleted rather than corrected. An omitted field is now a 422 naming it, which is what the endpoint description and the owner checklist have always told callers to expect ("send every field"), and what the console already enforces at compile time. Loud beats either flavour of silent.

The effective message-action policy for a workspace.