fix(docs): describe a self-issued credential by the kind it actually is

Round two returned the same finding on 14 pages: the one sentence covering
self-issued credentials still read as if the scope table were something to
apply to them. It cannot be one sentence, because the credential models
differ in what is true about them.

A Google service account is the sharp case. Its access comes from the key
and the domain-wide delegation granted in Workspace, and
`getServiceAccountToken` strips the two `userinfo` scopes from the JWT
because Google rejects user-identity scopes for a service account. Naming
those scopes beside that credential describes access it can never hold.
A pasted API token is the opposite: most have no permission picker at all
and simply carry their creating account's access, so any instruction to
grant something sends the reader looking for a setting that does not
exist.

Carry the `serviceAccountProviderId` through the docs catalog instead of a
boolean, and pick the sentence from it. Neither variant tells the reader to
match the table.

The excluded identity scopes now live in `scopes.ts` and
`credential-service.ts` imports them, so the published claim and the filter
that makes it true cannot drift apart.

The self-hosting reference gains one line saying what every table on it is:
the OAuth flow's request, and so what the app registration must allow. A
credential issued by hand is not governed by it.

Author: mzxchandra

apps/docs/content/docs/integrations/airtable.mdx

@@ -41,7 +41,7 @@ Connecting Airtable requests these scopes.
 | `user.email:read` | Read email address |
 | `webhook:manage` | Manage webhooks |
 
-Airtable also accepts a credential you create yourself. Sim cannot request scopes on one, so its access is whatever the credential carries: some providers let you select these permissions when you create the token, others give it the creating user's access.
+Airtable also accepts a credential you create yourself. Sim cannot request scopes on one, so its access is fixed when you create it, and it is generally whatever the account that created it can already do.
 
 
 ## Actions

apps/docs/content/docs/integrations/asana.mdx

@@ -38,7 +38,7 @@ Connecting Asana requests these scopes.
 | ----- | ----------- |
 | `default` | Access Asana workspace |
 
-Asana also accepts a credential you create yourself. Sim cannot request scopes on one, so its access is whatever the credential carries: some providers let you select these permissions when you create the token, others give it the creating user's access.
+Asana also accepts a credential you create yourself. Sim cannot request scopes on one, so its access is fixed when you create it, and it is generally whatever the account that created it can already do.
 
 
 ## Actions

apps/docs/content/docs/integrations/attio.mdx

@@ -46,7 +46,7 @@ Connecting Attio requests these scopes.
 | `user_management:read` | View workspace members |
 | `webhook:read-write` | Manage webhooks |
 
-Attio also accepts a credential you create yourself. Sim cannot request scopes on one, so its access is whatever the credential carries: some providers let you select these permissions when you create the token, others give it the creating user's access.
+Attio also accepts a credential you create yourself. Sim cannot request scopes on one, so its access is fixed when you create it, and it is generally whatever the account that created it can already do.
 
 
 ## Actions

apps/docs/content/docs/integrations/box.mdx

@@ -48,7 +48,7 @@ Connecting Box requests these scopes.
 | `root_readwrite` | Read and write all files and folders in Box account |
 | `sign_requests.readwrite` | Create and manage Box Sign e-signature requests |
 
-Box also accepts a credential you create yourself. Sim cannot request scopes on one, so its access is whatever the credential carries: some providers let you select these permissions when you create the token, others give it the creating user's access.
+Box also accepts a credential you create yourself. Sim cannot request scopes on one, so its access is fixed when you create it, and it is generally whatever the account that created it can already do.
 
 
 ## Actions

apps/docs/content/docs/integrations/confluence.mdx

@@ -73,7 +73,7 @@ Connecting Confluence requests these scopes.
 | `write:space.property:confluence` | Create and manage space properties |
 | `read:space.permission:confluence` | View Confluence space permissions |
 
-Confluence also accepts a credential you create yourself. Sim cannot request scopes on one, so its access is whatever the credential carries: some providers let you select these permissions when you create the token, others give it the creating user's access.
+Confluence also accepts a credential you create yourself. Sim cannot request scopes on one, so its access is fixed when you create it, and it is generally whatever the account that created it can already do.
 
 
 ## Actions

apps/docs/content/docs/integrations/gmail.mdx

@@ -46,7 +46,7 @@ Connecting Gmail requests these scopes.
 | `https://www.googleapis.com/auth/gmail.modify` | View and manage email messages |
 | `https://www.googleapis.com/auth/gmail.labels` | View and manage email labels |
 
-Gmail also accepts a credential you create yourself. Sim cannot request scopes on one, so its access is whatever the credential carries: some providers let you select these permissions when you create the token, others give it the creating user's access.
+Gmail also accepts a Google service account. Its access comes from the key and the domain-wide delegation you grant it in Google Workspace, not from this table, and Sim cannot add to it. The two `userinfo` scopes apply only to an OAuth connection: Google rejects them for a service account, so Sim leaves them out of that token.
 
 
 ## Actions

apps/docs/content/docs/integrations/google_bigquery.mdx

@@ -39,7 +39,7 @@ Connecting Google BigQuery requests these scopes.
 | `https://www.googleapis.com/auth/userinfo.profile` | View basic profile info |
 | `https://www.googleapis.com/auth/bigquery` | View and manage data in Google BigQuery |
 
-Google BigQuery also accepts a credential you create yourself. Sim cannot request scopes on one, so its access is whatever the credential carries: some providers let you select these permissions when you create the token, others give it the creating user's access.
+Google BigQuery also accepts a Google service account. Its access comes from the key and the domain-wide delegation you grant it in Google Workspace, not from this table, and Sim cannot add to it. The two `userinfo` scopes apply only to an OAuth connection: Google rejects them for a service account, so Sim leaves them out of that token.
 
 
 ## Actions

apps/docs/content/docs/integrations/google_calendar.mdx

@@ -43,7 +43,7 @@ Connecting Google Calendar requests these scopes.
 | `https://www.googleapis.com/auth/userinfo.profile` | View basic profile info |
 | `https://www.googleapis.com/auth/calendar` | View and manage calendar |
 
-Google Calendar also accepts a credential you create yourself. Sim cannot request scopes on one, so its access is whatever the credential carries: some providers let you select these permissions when you create the token, others give it the creating user's access.
+Google Calendar also accepts a Google service account. Its access comes from the key and the domain-wide delegation you grant it in Google Workspace, not from this table, and Sim cannot add to it. The two `userinfo` scopes apply only to an OAuth connection: Google rejects them for a service account, so Sim leaves them out of that token.
 
 
 ## Actions

apps/docs/content/docs/integrations/google_contacts.mdx

@@ -38,7 +38,7 @@ Connecting Google Contacts requests these scopes.
 | `https://www.googleapis.com/auth/userinfo.profile` | View basic profile info |
 | `https://www.googleapis.com/auth/contacts` | View and manage Google Contacts |
 
-Google Contacts also accepts a credential you create yourself. Sim cannot request scopes on one, so its access is whatever the credential carries: some providers let you select these permissions when you create the token, others give it the creating user's access.
+Google Contacts also accepts a Google service account. Its access comes from the key and the domain-wide delegation you grant it in Google Workspace, not from this table, and Sim cannot add to it. The two `userinfo` scopes apply only to an OAuth connection: Google rejects them for a service account, so Sim leaves them out of that token.
 
 
 ## Actions

apps/docs/content/docs/integrations/google_docs.mdx

@@ -41,7 +41,7 @@ Connecting Google Docs requests these scopes.
 | `https://www.googleapis.com/auth/drive.file` | View and manage Google Drive files |
 | `https://www.googleapis.com/auth/drive` | Access all Google Drive files |
 
-Google Docs also accepts a credential you create yourself. Sim cannot request scopes on one, so its access is whatever the credential carries: some providers let you select these permissions when you create the token, others give it the creating user's access.
+Google Docs also accepts a Google service account. Its access comes from the key and the domain-wide delegation you grant it in Google Workspace, not from this table, and Sim cannot add to it. The two `userinfo` scopes apply only to an OAuth connection: Google rejects them for a service account, so Sim leaves them out of that token.
 
 
 ## Actions