Resource type policy attachments are stored under the yoyaku_order third party key

ConstraintPolicyResolver reads and writes a resource type's policy attachments through the yoyaku_order third party key, at src/ConstraintPolicyResolver.php:150 and :185. The engine owns the constraint policy system, so it should own the key its attachments live under.

Two consequences. Attaching any policy to a resource type, including the engine's own transaction_quantity_limit, produces config that has no schema unless yoyaku_order is installed, because the schema is declared in modules/yoyaku_order/config/schema/yoyaku_order.schema.yml. A kernel test that installs only yoyaku and attaches a core policy to a resource type fails with SchemaIncompleteException, reporting that third_party_settings.yoyaku_order.policies is missing schema.

Second, that schema declares one flat mapping enumerating the settings of policies from three different modules, so every module shipping a policy has to have its settings named in a file it does not own. A schema derived per plugin id is the shape that scales.

Proposed resolution

Store the attachments under the yoyaku key, derive the settings schema per plugin id, and read the old key as a fallback so no stored attachment is orphaned.

The rewrite must ship as a migration script rather than a code change alone. An attachment whose key is nobody's to read enforces nothing, so a bare rename fails open and silently: every configured cap stops applying, with nothing in the log and the policy still listed on the host. That is the opposite of the fail closed behavior the missing plugin stand-in gives, and it is why this cannot be done as a code only change.