feat(form-builder): wire PurposeGuardProvider per purpose (WS-6)

Adds PurposeGuardProvider as a parallel interface to PurposeDefinition
(value object stays untouched). Seven concrete providers, one per v1.0
purpose, each declaring its publish-guard list. Registry resolves and
caches providers via guards_class config key.

Universal guards (MaxOneIdentityKeyPerTargetEntity,
AppendStrategyRequiresCollectionTarget, NoAmbiguousTrustLevels,
IdentityKeyBindingsOnlyInFirstSection) wire into every purpose. The
section guard is a cheap no-op when section_level_submit=false.

ArtistAdvanceGuards omits RequiresIdentityKeyBinding because the
artist subject is resolved via portal token, not form data. Same
reasoning for supplier_intake (production_request) and the auth-based
purposes.

Includes a cross-cutting BindingTypeRegistryConsistencyTest that
verifies tasks 5/7/8 do not contradict each other (registry ↔ guards ↔
purpose required_bindings).

Refs: RFC-WS-6.md §3 (Q9, Q13)

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

api/app/FormBuilder/Purposes/PurposeGuardProvider.php

@@ -0,0 +1,21 @@
+<?php
+
+declare(strict_types=1);
+
+namespace App\FormBuilder\Purposes;
+
+use App\FormBuilder\Publishing\PublishGuard;
+
+/**
+ * RFC-WS-6 §3 (Q13) — parallel interface to PurposeDefinition.
+ *
+ * The value object stays untouched (it's a frozen contract); guards
+ * live here so a new purpose can be added by composing two artifacts:
+ *   1. a PurposeDefinition entry in config/form_builder/purposes.php
+ *   2. a class implementing PurposeGuardProvider
+ */
+interface PurposeGuardProvider
+{
+    /** @return list<PublishGuard> */
+    public function publishGuards(): array;
+}