docs(approvals): state who can see a request, now that it is participant-scoped

The drift check flagged approvals.mdx, and rightly: it documented `approverId`
as one filter among several and never said who may see what — so a reader would
reasonably assume omitting it returns the whole tenant, which is exactly what
this PR stops being true.

Also records that a decision's attachments inherit the same rule, since that is
the non-obvious half: the file is as readable as the decision, never more.

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

Author: claude

content/docs/automation/approvals.mdx

@@ -244,6 +244,20 @@ a person's identities in one call.
 Other filters: `status`, `object`, `recordId`, `submitterId`, `q`, `limit`,
 `offset`.
 
+<Callout type="warn">
+**`approverId` is a filter, not authorization.** What you may see is decided
+separately: a request is visible to its **participants** — the submitter, a
+current approver, and anyone who has already acted on it (a past approver whose
+slot has moved on, a commenter). So omitting `approverId` returns *your*
+requests, not every request in the tenant. Admins with override authority
+(`admin_full_access`, or `organization_admin` within their org) see all of them
+— that is what the "all requests" view is for.
+
+The same rule governs a decision's files: an attachment is exactly as readable
+as the decision it hangs off, never more (`sys_approval_action` delegates that
+question back to this service via `fileAccessDelegate`).
+</Callout>
+
 <Callout type="warn">
 **Opening a request notifies nobody.** There is no built-in "you have an
 approval waiting" message today — an approver only discovers it by looking at