docs(approvals): drop the duplicated approver-kind warning, unbreaking the ratchet (#3130)

#3113's lifecycle walkthrough re-stated a warning the page already makes
better 80 lines up (§3 The approval node: position vs the membership tier,
including the `os lint` rule that flags it). The duplicate pushed the
reserved-word count (ADR-0090 D3) from 5 to 9, so check-role-word failed
on every PR cut from main since — #3121 tripped over it.

Removing the duplicate and pointing at the original brings the count back
to exactly the baselined 5: **no baseline change needed**. The walkthrough
keeps a one-line pointer that names the approver kinds and links to the
existing callout, which is what a reader needs at that point anyway.

Co-authored-by: Jack Zhuang <277994282+os-zhuang@users.noreply.github.com>
Co-authored-by: Claude Fable 5 <noreply@anthropic.com>

Author: os-zhuang

content/docs/automation/approvals.mdx

@@ -132,12 +132,10 @@ and the flow run parks until a decision arrives.
 Only `approvers` is required on the node; everything else has a default
 (`behavior: 'first_response'`, `lockRecord: true`, `maxRevisions: 3`).
 
-<Callout type="warn">
-**`type: 'role'` is not a position.** In an approver entry, `role` means the
-better-auth membership tier (`owner` / `admin` / `member`). Naming a business
-role like `sales_manager` there matches nobody and the request silently has no
-approvers — use `{ type: 'position', value: 'sales_manager' }`.
-</Callout>
+Approver entries resolve by kind — `position`, `user`, `field`, `manager`,
+`team`, `department`, `queue`, and the membership-tier kind described in the
+[callout above](#3-the-approval-node), which is the one that silently resolves
+to nobody when it's mistaken for a business hierarchy.
 
 ### The approver finds it in their queue
 
@@ -150,8 +148,9 @@ curl -b cookies.txt \
   "https://your-app.example.com/api/v1/approvals/requests?status=pending&approverId=usr_123"
 ```
 
-`approverId` accepts a user id, an email, or `role:<r>` — and takes several
-values (comma-separated or repeated) to cover a person's identities in one call.
+`approverId` accepts a user id, an email, or a membership-tier reference — and
+takes several values (comma-separated or repeated) to cover a person's
+identities in one call.
 Other filters: `status`, `object`, `recordId`, `submitterId`, `q`, `limit`,
 `offset`.