[CRED-2815] Document PAT/SAT scope, TTL, and app-key restrictions

[emubello]

What changed

Adds a Restrictions section to the Personal Access Tokens and Service Access Tokens documentation.

The new sections document containment rules for API calls authenticated with a PAT or SAT:

• Cannot create or update application keys. Revocation is still allowed.
• Cannot create or update another token with scopes broader than its own.
• Cannot create a token with a TTL that outlives itself.

Calls that violate these restrictions return a 403 Forbidden response.

Why

This redoes the changes from #38945 on a fresh branch after the docs repo reorg. The content now targets the current hugo/content/... paths.

Validation

• git diff --check
• vale hugo/content/en/account_management/personal-access-tokens.md hugo/content/en/account_management/service-access-tokens.md

Vale reports no errors. Remaining warnings/suggestions are pre-existing lines in these files.

[github-actions]

Preview links (active after the build_preview check completes)

Modified Files

• https://docs-staging.datadoghq.com/emu/cred-2815/reopen-pat-sat-restrictions/account_management/personal-access-tokens
• https://docs-staging.datadoghq.com/emu/cred-2815/reopen-pat-sat-restrictions/account_management/service-access-tokens

[evazorro]

A PAT can create a SAT, but can a SAT create a PAT? If not, could be worth mentioning as a restriction in the list

[evazorro]

Suggested change

	These restrictions apply only to API calls authenticated with a PAT or SAT. A call that violates one of these restrictions returns a `403 Forbidden` response.
	A call that violates one of these restrictions returns a `403 Forbidden` response.

The first sentence duplicates your intro sentence here, so I don't think you need it

[evazorro]

Suggested change

	These restrictions apply only to API calls authenticated with a PAT or SAT. A call that violates one of these restrictions returns a `403 Forbidden` response.
	A call that violates one of these restrictions returns a `403 Forbidden` response.

Same reasoning here

[evazorro]

Suggested change

	- **Time-to-live (TTL) on new tokens**: A PAT cannot create a PAT or a SAT with a TTL that outlives itself.
	- **Time-to-live (TTL) on new tokens**: A PAT cannot create a PAT or a SAT with a TTL that extends beyond its own expiration.

"itself" was a little unclear, rephrasing to clarify

[evazorro]

Suggested change

	- **Time-to-live (TTL) on new tokens**: A SAT cannot create a SAT with a TTL that outlives itself.
	- **Time-to-live (TTL) on new tokens**: A SAT cannot create a SAT with a TTL that extends beyond its own expiration.

[evazorro]

Suggested change

	## Restrictions
	## Restrictions on PAT-authenticated API calls

Makes the header clearer in case this section is retrieved in isolation (like by an AI agent)

[evazorro]

Suggested change

	## Restrictions
	## Restrictions on SAT-authenticated API calls

[evazorro]

Suggested change

	To limit how a SAT can escalate its own access, Datadog restricts what an API call authenticated with a SAT can do. These restrictions apply regardless of the API client making the call:
	To prevent privilege escalation, Datadog restricts what an API call authenticated with a SAT can do. These restrictions apply regardless of the API client making the call:

Avoids personifying the SAT

[evazorro]

Suggested change

	To limit how a PAT can escalate its own access, Datadog restricts what an API call authenticated with a PAT can do. These restrictions apply regardless of the API client making the call:
	To prevent privilege escalation, Datadog restricts what an API call authenticated with a PAT can do. These restrictions apply regardless of the API client making the call:

Same here

[emubello]

Hi @evazorro a SAT cannot create a PAT, since it will be owned by a service account, thus making it a SAT as well. Do you think I should call out this distinction?