Docs: note that the status filters are now enforced

src/hooks/filters/payment.md

@@ -117,7 +117,16 @@ $paymentStatuses = [
 
 `apply_filters('fluentform/available_payment_statuses', $paymentStatuses);`
 
-This filter is located in FluentFormPro\src\Payments\PaymentHelper -> getPaymentStatuses()
+::: warning Registering a custom status is required
+Changing a transaction's status from the admin is validated against this list, so a status
+that is not registered here cannot be selected or applied.
+
+Validation only runs when the status actually changes. A row that already holds a status
+this build does not register keeps it, and its other fields (payer name, email, addresses)
+remain editable.
+:::
+
+Two classes define this list and both apply the filter: `FluentForm\App\Modules\Payments\PaymentHelper` (free) and `FluentFormPro\Payments\PaymentHelper` (Pro). The array above is Pro's — `requires_review` is Pro-only and is not present in the free list, so register any status you rely on through the filter rather than assuming a hardcoded default.
 
 </explain-block>
 

src/hooks/filters/submission.md

@@ -345,6 +345,16 @@ add_filter('fluentform/entry_statuses_core', function ($statuses , $form_id) {
 
 This filter is located in FluentForm\App\Helpers\Helper -> getEntryStatuses($form_id = false)
 
+::: warning Registering a custom status is required
+Entry status writes are validated against this list. A status that is not registered here
+cannot be set — neither the bulk action nor the single-entry endpoint will apply it.
+
+The list is resolved per form, and add-ons that gate their statuses on a feature being
+active (Admin Approval, double opt-in) only contribute while that feature is enabled for
+the form. Existing rows keep a status after the feature is turned off, but it can no longer
+be re-applied; the base statuses stay available for triage.
+:::
+
 </explain-block>
 
 <explain-block title="fluentform/export_data">