docs: payload proper nouns (#11792)

Uses proper nouns in the docs where necessary for "Payload" and "Local
API".

Author: jacobsfletch

docs/admin/customizing-css.mdx

@@ -45,7 +45,7 @@ To override existing styles in a way that the previous rules of specificity woul
 
 ```css
 @layer payload-default {
-  // my styles within the payload specificity
+  // my styles within the Payload specificity
 }
 ```
 

docs/authentication/operations.mdx

@@ -353,7 +353,7 @@ const token = await payload.forgotPassword({
   data: {
     email: 'dev@payloadcms.com',
   },
-  disableEmail: false, // you can disable the auto-generation of email via local API
+  disableEmail: false, // you can disable the auto-generation of email via Local API
 })
 ```
 
@@ -370,7 +370,7 @@ const token = await payload.forgotPassword({
 <Banner type="success">
   **Tip:**
 
-You can stop the reset-password email from being sent via using the local API. This is helpful if
+You can stop the reset-password email from being sent via using the Local API. This is helpful if
 you need to create user accounts programmatically, but not set their password for them. This
 effectively generates a reset password token which you can then use to send to a page you create,
 allowing a user to "complete" their account by setting their password. In the background, you'd

docs/configuration/localization.mdx

@@ -107,7 +107,7 @@ _\* An asterisk denotes that a property is required._
 In some projects you may want to filter the available locales shown in the admin UI selector. You can do this by providing a `filterAvailableLocales` function in your Payload Config. This is called on the server side and is passed the array of locales. This means that you can determine what locales are visible in the localizer selection menu at the top of the admin panel. You could do this per user, or implement a function that scopes these to tenants and more. Here is an example using request headers in a multi-tenant application:
 
 ```ts
-// ... rest of payload config
+// ... rest of Payload config
 localization: {
   defaultLocale: 'en',
   locales: ['en', 'es'],

docs/database/migrations.mdx

@@ -53,7 +53,7 @@ export async function down({ payload, req }: MigrateDownArgs): Promise<void> {
 ## Using Transactions
 
 When migrations are run, each migration is performed in a new [transaction](/docs/database/transactions) for you. All
-you need to do is pass the `req` object to any [local API](/docs/local-api/overview) or direct database calls, such as
+you need to do is pass the `req` object to any [Local API](/docs/local-api/overview) or direct database calls, such as
 `payload.db.updateMany()`, to make database changes inside the transaction. Assuming no errors were thrown, the transaction is committed
 after your `up` or `down` function runs. If the migration errors at any point or fails to commit, it is caught and the
 transaction gets aborted. This way no change is made to the database if the migration fails.

docs/database/transactions.mdx

@@ -69,15 +69,15 @@ const afterChange: CollectionAfterChangeHook = async ({ req }) => {
 
 ## Direct Transaction Access
 
-When writing your own scripts or custom endpoints, you may wish to have direct control over transactions. This is useful for interacting with your database outside of Payload's local API.
+When writing your own scripts or custom endpoints, you may wish to have direct control over transactions. This is useful for interacting with your database outside of Payload's Local API.
 
 The following functions can be used for managing transactions:
 
 - `payload.db.beginTransaction` - Starts a new session and returns a transaction ID for use in other Payload Local API calls.
 - `payload.db.commitTransaction` - Takes the identifier for the transaction, finalizes any changes.
 - `payload.db.rollbackTransaction` - Takes the identifier for the transaction, discards any changes.
 
-Payload uses the `req` object to pass the transaction ID through to the database adapter. If you are not using the `req` object, you can make a new object to pass the transaction ID directly to database adapter methods and local API calls.
+Payload uses the `req` object to pass the transaction ID through to the database adapter. If you are not using the `req` object, you can make a new object to pass the transaction ID directly to database adapter methods and Local API calls.
 Example:
 
 ```ts
@@ -91,7 +91,7 @@ const standalonePayloadScript = async () => {
   const transactionID = await payload.db.beginTransaction()
 
   try {
-    // Make an update using the local API
+    // Make an update using the Local API
     await payload.update({
       collection: 'posts',
       data: {
@@ -123,7 +123,7 @@ standalonePayloadScript()
 
 If you wish to disable transactions entirely, you can do so by passing `false` as the `transactionOptions` in your database adapter configuration. All the official Payload database adapters support this option.
 
-In addition to allowing database transactions to be disabled at the adapter level. You can prevent Payload from using a transaction in direct calls to the local API by adding `disableTransaction: true` to the args. For example:
+In addition to allowing database transactions to be disabled at the adapter level. You can prevent Payload from using a transaction in direct calls to the Local API by adding `disableTransaction: true` to the args. For example:
 
 ```ts
 await payload.update({

docs/fields/join.mdx

@@ -236,11 +236,11 @@ The following query options are supported:
 | **`sort`**  | A string used to order related results                                                              |
 | **`count`** | Whether include the count of related documents or not. Not included by default                      |
 
-These can be applied to the local API, GraphQL, and REST API.
+These can be applied to the Local API, GraphQL, and REST API.
 
 ### Local API
 
-By adding `joins` to the local API you can customize the request for each join field by the `name` of the field.
+By adding `joins` to the Local API you can customize the request for each join field by the `name` of the field.
 
 ```js
 const result = await payload.find({
@@ -287,7 +287,7 @@ const result = await payload.find({
 
 ### Rest API
 
-The rest API supports the same query options as the local API. You can use the `joins` query parameter to customize the
+The REST API supports the same query options as the Local API. You can use the `joins` query parameter to customize the
 request for each join field by the `name` of the field. For example, an API call to get a document with the related
 posts limited to 5 and sorted by title:
 

docs/graphql/extending.mdx

@@ -70,7 +70,7 @@ export default buildConfig({
 
 ## Resolver function
 
-In your resolver, make sure you set `depth: 0` if you're returning data directly from the local API so that GraphQL can correctly resolve queries to nested values such as relationship data.
+In your resolver, make sure you set `depth: 0` if you're returning data directly from the Local API so that GraphQL can correctly resolve queries to nested values such as relationship data.
 
 Your function will receive four arguments you can make use of:
 

docs/graphql/graphql-schema.mdx

@@ -60,7 +60,7 @@ type Collection1 {
 }
 ```
 
-The above example outputs all your definitions to a file relative from your payload config as `./graphql/schema.graphql`. By default, the file will be output to your current working directory as `schema.graphql`.
+The above example outputs all your definitions to a file relative from your Payload config as `./graphql/schema.graphql`. By default, the file will be output to your current working directory as `schema.graphql`.
 
 ### Adding an npm script
 

docs/hooks/context.mdx

@@ -14,7 +14,7 @@ Context gives you a way forward on otherwise difficult problems such as:
 
 1. **Passing data between Hooks**: Needing data in multiple Hooks from a 3rd party API, it could be retrieved and used in `beforeChange` and later used again in an `afterChange` hook without having to fetch it twice.
 2. **Preventing infinite loops**: Calling `payload.update()` on the same document that triggered an `afterChange` hook will create an infinite loop, control the flow by assigning a no-op condition to context
-3. **Passing data to local API**: Setting values on the `req.context` and pass it to `payload.create()` you can provide additional data to hooks without adding extraneous fields.
+3. **Passing data to Local API**: Setting values on the `req.context` and pass it to `payload.create()` you can provide additional data to hooks without adding extraneous fields.
 4. **Passing data between hooks and middleware or custom endpoints**: Hooks could set context across multiple collections and then be used in a final `postMiddleware`.
 
 ## How To Use Context

docs/jobs-queue/queues.mdx

@@ -39,7 +39,7 @@ export default buildConfig({
     tasks: [
       // your tasks here
     ],
-    // autoRun can optionally be a function that receives payload as an argument
+    // autoRun can optionally be a function that receives `payload` as an argument
     autoRun: [
       {
         cron: '0 * * * *', // every hour at minute 0