docs(permissions): document the accepted status filter values on /security/suggested-bindings (#4127)

The 400 introduced alongside the slot-contract ledger is observable API
behaviour, and this page is where the endpoint is documented. Both existing
examples already used valid statuses, so nothing here was invalidated — what was
missing is that the filter has a fixed set at all, and what an unknown value now
does instead of quietly returning an empty list.

Refs #4127

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_015T5CeitwV1jXLvsL1A84tw

Author: claude

content/docs/permissions/permission-sets.mdx

@@ -204,6 +204,11 @@ POST /api/v1/security/suggested-bindings/:id/confirm      # create the everyone
 POST /api/v1/security/suggested-bindings/:id/dismiss      # decline the prompt
 ```
 
+`status` accepts `pending`, `confirmed` or `dismissed`, and may be omitted to
+list every suggestion. Any other value is rejected with a `400` naming the
+accepted set — it previously reached the query as a filter nothing matched, so
+a mistyped status returned an empty list that read as "no suggestions".
+
 All three require a tenant-level administrator (the anchors are tenant-level
 only — D12). Confirm writes the `sys_position_permission_set` row **as the
 caller**, so the audience-anchor gate re-checks the forbidden-bits predicate