feat(form-builder): form_field_configs relational table + non-validation key split + drop validation_rules JSON columns

dev-docs/ARCH-FORM-BUILDER.md

@@ -1,13 +1,19 @@
-# ARCH — Universal Form Builder (v1.5)
+# ARCH — Universal Form Builder (v1.6)
 
 > **Source of truth** for Crewli's universal Form Builder architecture.
 > Any discrepancy with SCHEMA.md is resolved in favour of this document
 > during the refactor. SCHEMA.md is updated at the end of the refactor.
 >
 > **Status:** Approved — WS-5a landed (relational `form_field_bindings`);
-> WS-5b validation rules landed (relational `form_field_validation_rules`).
-> **Version:** 1.5 (§17.4 restructured into relational sub-sections:
-> catalogue, relational table, callback rules, legacy JSON migration).
+> WS-5b landed in full (relational `form_field_validation_rules` and
+> parallel `form_field_configs`; pre-WS-5b `validation_rules` JSON
+> columns dropped).
+> **Version:** 1.6 (new §17.5 "Field configuration (non-validation)" for
+> the `form_field_configs` split; §17.4.4 updated with the
+> non-validation-key relocation note).
+> **Previous:**
+> 1.5 (§17.4 restructured into relational sub-sections: catalogue,
+>   relational table, callback rules, legacy JSON migration).
 > **Previous versions:**
 > 1.4 (§6.3 retitled to "Binding row specification"; new §6.7 "Relational
 >   binding table"; §17.3 pre-publish check in present tense per WS-5a),
@@ -2410,13 +2416,112 @@ Those rows are immutable records and are not rewritten by the
 migration. Snapshot readers must tolerate both shapes — pre-WS-5b
 legacy keys and post-WS-5b canonical keys.
 
-### 17.5 Webhooks
+### 17.5 Field configuration (non-validation)
 
-#### 17.5.1 Schema
+Per-field configuration that is *not* validation (tag-picker category
+filters, upload disk selection) lives in the relational
+`form_field_configs` table — a deliberate sibling to §17.4's
+`form_field_validation_rules`, not a merger. Two tables with clear
+semantics beat one table that drifts into "bucket for everything that
+doesn't fit elsewhere".
+
+#### 17.5.1 Why this is separate from `validation_rules`
+
+Pre-WS-5b, `form_fields.validation_rules` was a grab-bag that held
+validation *and* non-validation keys. Keeping the non-validation keys
+in a table named `form_field_validation_rules` would have poisoned that
+table's meaning and re-introduced the drift WS-5 was cleaning up. The
+strict-enterprise resolution on the Q3 WS-5b decision gate was: split
+the non-validation keys into their own relational home with matching
+semantics ("table name = table contents"), at the cost of one extra
+table, one extra enum, one extra service, one extra scope. The
+architecture decision log is in
+`/dev-docs/ARCH-CONSOLIDATION-ADDENDUM-2026-04-24.md` §Q3 WS-5b
+Uitvoering.
+
+#### 17.5.2 Table `form_field_configs` and config-type catalogue
+
+**Columns** (SCHEMA.md §3.5.12):
+
+| Column         | Type              | Notes                                                      |
+| -------------- | ----------------- | ---------------------------------------------------------- |
+| `id`           | ULID              | PK                                                         |
+| `owner_type`   | string(40)        | morph alias: `form_field` or `form_field_library`          |
+| `owner_id`     | ULID              | parent row                                                 |
+| `config_type`  | string(40)        | enum case value                                            |
+| `parameters`   | JSON              | per-config-type bag                                        |
+| `created_at`, `updated_at` | timestamps |                                                            |
+
+**Catalogue (`FormFieldConfigType`):**
+
+| `config_type`     | `parameters` shape              | Consumed by                                                                                   |
+| ----------------- | ------------------------------- | --------------------------------------------------------------------------------------------- |
+| `tag_categories`  | `{"categories": [string]}`      | `FormFieldResource` + `PublicFormSchemaResource` — filters `person_tags` options for TAG_PICKER fields |
+| `storage_disk`    | `{"disk": string}`              | `FormValueService` (file-upload handling — WS-6) — overrides the default filesystem disk      |
+
+Both config types are app-enforced, not DB enum — same rationale as
+§17.4.1 (runtime extensibility via registry).
+
+#### 17.5.3 Service, scope, cascade, activity log
+
+Mirrors §17.4's validation-rules stack one-for-one:
+
+- **Service boundary** (`FormFieldConfigService`) — `configsFor`,
+  `replaceConfigs`, `copyConfigs`, `toJsonShape`, `assertSpecsValid`.
+  Single writer; all controller paths go through it.
+- **Multi-tenancy** (`FormFieldConfigScope`) — third near-duplicate of
+  `FormFieldBindingScope`. The three siblings' base-class extraction is
+  deferred to WS-5d per addendum Q3 (abstracting from three is still
+  premature when the fourth sibling is about to land and may clarify
+  what truly varies).
+- **Cascade** — shared `FormFieldChildTablesCascadeObserver` (renamed
+  from `FormFieldBindingsCascadeObserver` in WS-5b commit 1) covers
+  all three relational tables on owner delete.
+- **Activity log** — two entries emit on config changes on a
+  FormField subject: `field.updated` (reconstructed `configs` via
+  `toJsonShape`) and `field.configs_replaced` (semantic event). Matches
+  the §6.7 / §17.4.2 pattern. Library-level changes are silent in
+  activity log; consumers that need them listen at a different layer.
+
+#### 17.5.4 Snapshot embedding
+
+`form_submissions.schema_snapshot.fields[*]` gains a top-level `configs`
+key alongside `validation_rules`:
+
+```json
+{
+  "id": "01H...",
+  "slug": "vaardigheden",
+  "field_type": "TAG_PICKER",
+  "validation_rules": null,
+  "configs": { "tag_categories": { "categories": ["Veiligheid"] } },
+  ...
+}
+```
+
+Historical snapshots written before WS-5b commit 5 continue to embed
+the merged shape (`validation_rules: {"tag_categories": [...], "min":
+3}`) with no `configs` key — those rows are immutable records. Readers
+must tolerate both shapes.
+
+#### 17.5.5 External API contract change
+
+WS-5b commit 5 is a breaking change to the form-field JSON contract.
+Pre-WS-5b: `field.validation_rules.tag_categories`. Post-WS-5b:
+`field.configs.tag_categories.categories`. Same for `storage_disk`.
+The portal + organizer SPAs are updated in the same work package
+(WS-5b commit 5); there is no bridging compatibility layer. See the
+"Breaking change acceptance" note at the top of this document.
+
+---
+
+### 17.6 Webhooks
+
+#### 17.6.1 Schema
 
 See §4.11 `form_schema_webhooks` and §4.12 `form_webhook_deliveries`.
 
-#### 17.5.2 Dispatcher
+#### 17.6.2 Dispatcher
 
 `FormWebhookDispatcher` listens for FormSubmissionSubmitted / Reviewed /
 SectionSubmitted / SectionReviewed events. On trigger:
@@ -2424,7 +2529,7 @@ SectionSubmitted / SectionReviewed events. On trigger:
 - For each: creates a form_webhook_delivery row with status=pending
 - Queues `DeliverFormWebhookJob` per delivery on dedicated `webhooks` queue
 
-#### 17.5.3 Delivery job
+#### 17.6.3 Delivery job
 
 `DeliverFormWebhookJob` on `webhooks` queue:
 - Idempotent (Laravel job with unique ID per delivery)
@@ -2443,7 +2548,7 @@ SectionSubmitted / SectionReviewed events. On trigger:
 Response body first 1000 chars stored in `response_body_excerpt` for
 debugging.
 
-#### 17.5.4 Security
+#### 17.6.4 Security
 
 URL validation in `FormWebhookDispatcher`:
 - Parse URL; reject non-http(s)
@@ -2455,7 +2560,7 @@ URL validation in `FormWebhookDispatcher`:
 
 Admin UI shows validation status + last delivery attempt per webhook.
 
-#### 17.5.5 Webhook payload format
+#### 17.6.5 Webhook payload format
 
 ```json
 {