Make the Policy Workbench compound helper use policy definitions #8687

Part of #8684. #8686 is complete.

Goal

Make the existing Policy Workbench compound helper support more than one child policy.

The backend exposes compound relationships through:

parent policy + meta.compositeChildren[]

This is the source of truth for compound membership.

Current backend definitions already expose:

maximum_validity -> renewal_interval
signing_mode -> worker_config
signature_rejection -> rejection_* children

The existing signature stamp editor also combines signature_stamp with collect_metadata, but that relationship is not yet declared by the backend. As part of this issue, add the minimal backend contract needed to expose:

signature_stamp -> collect_metadata

through meta.compositeChildren.

Do not create another frontend list of child policy keys and do not add a frontend fallback for missing compositeChildren.

The backend change here is limited to declaring the existing compound relationship. Do not change authorization, persistence semantics, or turn collect_metadata into a helper/catalog-hidden policy unless independently required by an existing contract.

Definition contract

Add a generic compound mapping to RealPolicySettingDefinition.

Use this shape, or the closest equivalent that follows the current TypeScript style:

interface RealPolicyCompoundBehavior {
  compose: (
    valuesByPolicyKey: Record<string, EffectivePolicyValue | undefined>,
  ) => EffectivePolicyValue

  decompose: (
    editorValue: EffectivePolicyValue,
  ) => Record<string, EffectivePolicyValue>
}

interface RealPolicySettingDefinition {
  // existing fields...
  compound?: RealPolicyCompoundBehavior
}

The parent key is definition.key.

The child keys come from:

policy.meta?.compositeChildren ?? []

The shared engine loads those keys and passes the keyed values to compose().

When saving, it passes the editor value to decompose() and sends the returned keyed values through the compound store methods from #8686.

Keep policy logic local

The shared engine must not know how a specific policy combines its values.

Keep or move that mapping to the related policy module.

Existing compound settings must keep working:

• request expiration;
• signing execution;
• signature stamp / collect metadata.

For signature stamp, expose the existing signature_stamp -> collect_metadata relationship from the backend and consume it through meta.compositeChildren. Do not hard-code collect_metadata as a fallback child in the shared Workbench engine.

Do not move their normalization rules into useRealPolicyWorkbench.ts.

Clear/reset

The backend has no compound DELETE endpoint.

Keep using the existing clear methods for each persisted member.

If one clear fails:

• show the existing Workbench error;
• reload persisted/effective state;
• do not keep a UI state that assumes all members were cleared.

Do not add a backend DELETE endpoint in this issue.

Main files

Start with:

src/views/Settings/PolicyWorkbench/settings/realTypes.ts
src/views/Settings/PolicyWorkbench/policyWorkbenchCompoundPolicies.ts
src/views/Settings/PolicyWorkbench/useRealPolicyWorkbench.ts
lib/Service/Policy/Provider/SignatureText/SignatureTextPolicy.php

Update only the existing compound policy modules and the minimal backend definition needed for the mapping contract.

Security

Do not change authorization behavior.

Continue using backend:

• meta.compositeChildren;
• allowedValues;
• editableByCurrentActor;
• delegation metadata;
• save validation.

Frontend code must not widen permissions.

Tests

Update the existing compound-policy tests.

Cover:

• a parent with at least two children;
• child keys come from meta.compositeChildren;
• missing meta.compositeChildren does not cause the shared engine to invent frontend child keys;
• compose() receives keyed parent/child values;
• decompose() produces the keyed write payload;
• system/group/user hydration still works;
• save uses the compound store method from Add compound policy write methods to the policies store #8686;
• existing compound policies keep working;
• signature_stamp exposes collect_metadata through backend compound metadata;
• helper children do not become catalog settings;
• collect_metadata keeps its existing independent catalog behavior.

Add/update the focused backend definition test for the signature_stamp -> collect_metadata relationship.

Done when

• Compound policies are not limited to one companion.
• Child keys come from backend metadata.
• No frontend fallback list of compound child keys exists.
• signature_stamp -> collect_metadata is exposed by the backend definition.
• Policy-specific mapping is defined by the policy module.
• Existing compound policies keep working.
• Compound saves use Add compound policy write methods to the policies store #8686.
• No Signature Rejection-specific branch is added.
• Focused frontend and backend tests pass.
• npm run lint passes.
• npm run ts:check passes.