docs(forms): the public picker's search is authorized by the guest set, and answers 403 PERMISSION_DENIED without one

Three passages said the picker's results were bounded by its declaration
alone and that the guest set was only a back-compat leftover. Under the
deny baseline a search context that resolves no permission set is refused
at object admission, so the picker needs a guest set that grants read on
its target object; the errors table gains that answer.

Claude-Session: https://claude.ai/code/session_01DiCSbmJrkzNhuEAier4VoJ
Co-authored-by: Claude <noreply@anthropic.com>

Author: claude

content/docs/ui/forms.mdx

@@ -103,12 +103,19 @@ export default defineView({
 
 ## 2. (Optional) Create the `guest_portal` permission set
 
-Authorization no longer depends on this set — the declaration-derived
-`publicFormGrant` (see the note above) is what permits the insert. You only need
-a `guest_portal` permission set if you rely on the legacy back-compat path (e.g.
-an older runtime, or object hooks that branch on the `guest_portal` permission).
-When present it is still attached to the anonymous context, so keep it
-INSERT-only on the target object — the guest-safe shape (ADR-0090 D9).
+The submit's authorization no longer depends on this set — the
+declaration-derived `publicFormGrant` (see the note above) is what permits the
+insert. For the submit you only need a `guest_portal` permission set if you rely
+on the legacy back-compat path (e.g. an older runtime, or object hooks that
+branch on the `guest_portal` permission). A form that declares a public picker
+(see *the public picker* below) is different: the picker's search runs under
+this set and nothing else, so without one that grants read on the picker's
+target object the picker answers `403 PERMISSION_DENIED` — the ADR-0056 D2 deny
+baseline refuses a caller that resolves no permission set. When present the set
+is attached to the anonymous context, so keep it INSERT-only on the form's
+target object — the guest-safe shape (ADR-0090 D9) — and remember that any read
+you grant a picker's target object is readable by every anonymous visitor
+through that picker.
 
 {/* os:check */}
 ```ts
@@ -284,14 +291,15 @@ Errors:
 |---|---|---|
 | `400 INVALID_REQUEST` | missing / blank slug or field |
 | `403 LOOKUP_NOT_PUBLIC` | the field has no `publicPicker` block — the deliberate loud default (#3022); also any server-managed anchor (`owner_id`, `organization_id`, …), which never gets a picker even if one is declared |
+| `403 PERMISSION_DENIED` | the deployment registers no `guest_portal` set that grants read on the picker's target object, so the search context resolves no permission set and is refused at object admission — the ADR-0056 D2 deny baseline. The picker's declaration bounds what is searched and projected; it never grants the read itself |
 | `404 FORM_NOT_FOUND` | slug not registered on any `sharing.allowAnonymous: true` view |
 | `500 LOOKUP_TARGET_MISSING` | the referenced object could not be resolved from either `publicPicker.object` or the field definition — the field names no target object at all (or its object metadata is unreachable). Until #7486 this also fired for a perfectly well-formed field, because the fallback read only the legacy spellings and not the canonical `reference`; declaring `object` was the workaround and is no longer needed. |
 | `500 INTERNAL_ERROR` | the field def **declares** a target this route cannot READ — a stored `reference` holding an object or an array rather than the object name `FieldSchema` declares. ⚠️ Deliberately **not** `LOOKUP_TARGET_MISSING`: "nothing names the target" and "the named target is unreadable" want different fixes from whoever owns the metadata, so they get different answers. The unreadable carrier is named in full in the server log (it is withheld from the response body, as every fault's text is); the picker's search never runs. |
 
 ### Auth model
 
 - None of the three routes calls `enforceAuth`, so they work under the always-on anonymous-deny default (there is no `requireAuth` knob to configure since v17).
-- The execution context the **submit** route hands to ObjectQL is `{ publicFormGrant: { object }, permissions: ['guest_portal'], anonymous: true }` with no `userId`. The Security plugin honors `publicFormGrant` first — a create + read-back grant scoped to exactly the declared object — so authorization holds even without a `guest_portal` profile. `permissions: ['guest_portal']` is retained for back-compat. The **lookup** route's search context is `{ permissions: ['guest_portal'], anonymous: true }` — no `publicFormGrant` (it reads the picker's target object, not the form's), which is why its result set is bounded by the picker declaration instead.
+- The execution context the **submit** route hands to ObjectQL is `{ publicFormGrant: { object }, permissions: ['guest_portal'], anonymous: true }` with no `userId`. The Security plugin honors `publicFormGrant` first — a create + read-back grant scoped to exactly the declared object — so authorization holds even without a `guest_portal` profile. `permissions: ['guest_portal']` is retained for back-compat. The **lookup** route's search context is `{ permissions: ['guest_portal'], anonymous: true }` — no `publicFormGrant` (it reads the picker's target object, not the form's), so the picker declaration bounds what the search matches and projects, and the deployment's `guest_portal` set is what authorizes it: with no such set granting read on the target object, the search context resolves no permission set and is refused at object admission (`403 PERMISSION_DENIED`, the ADR-0056 D2 deny baseline).
 - No CSRF or auth header is needed; embed the form on any domain.
 
 ## 5. Embedding from a front-end