Fix vale issues

Author: Swimburger

fern/products/sdks/overview/typescript/publishing-to-npm.mdx

@@ -106,10 +106,10 @@ groups:
 
 ## Configure authentication
 
-Choose how you want to authenticate with npmjs when publishing. **OIDC is strongly recommended** for security.
+Choose how you want to authenticate with npmjs when publishing. **OpenID Connect (OIDC) is strongly recommended** for security.
 
 <Note>
-**Starting in early 2025**, npmjs.org is deprecating long-lived authentication tokens for publishing from CI/CD workflows. We recommend using OIDC-based authentication.
+**Starting in early 2025**, npmjs.org is deprecating long-lived authentication tokens for publishing from CI/CD workflows. OIDC-based authentication is recommended.
 </Note>
 
 <AccordionGroup>
@@ -193,7 +193,7 @@ Common causes:
 
 **Private repository limitations**
 
-Provenance attestations are not generated for packages published from private repositories, even when using trusted publishing. This is a [known limitation](https://github.blog/changelog/2023-07-25-publishing-with-npm-provenance-from-private-source-repositories-is-no-longer-supported/).
+Provenance attestations aren't generated for packages published from private repositories, even when using trusted publishing. This is a [known limitation](https://github.blog/changelog/2023-07-25-publishing-with-npm-provenance-from-private-source-repositories-is-no-longer-supported/).
 
 </Accordion>
 
@@ -202,7 +202,7 @@ Provenance attestations are not generated for packages published from private re
 <Accordion title="Token-based authentication (Legacy)">
 
 <Warning>
-**This method is being deprecated by npmjs.org in early 2025.** We strongly recommend using OIDC-based authentication instead. Long-lived authentication tokens can be accidentally exposed in logs, compromised, and are difficult to manage and rotate.
+**This method is being deprecated by npmjs.org in early 2025.** OIDC-based authentication is strongly recommended instead. Long-lived authentication tokens can be exposed in logs, compromised, and are difficult to manage and rotate.
 </Warning>
 
 <Steps>
@@ -261,7 +261,7 @@ groups:
 
 Your SDK will automatically be published to npmjs when you create a GitHub release with a version tag:
 
-1. Create a GitHub release with a version tag (e.g., `v1.0.0`)
+1. Create a GitHub release with a version tag (for example, `v1.0.0`)
 1. The CI workflow will run automatically and publish to npm
 1. View your package on npmjs.com to confirm the new version
 
@@ -308,13 +308,13 @@ If you're currently using token-based authentication and need to migrate to OIDC
 
 ### Why migrate to OIDC
 
-npm is implementing trusted publishing to eliminate security risks associated with long-lived tokens, which can be:
+npmjs is implementing trusted publishing to remove security risks associated with long-lived tokens, which can be:
 
-- Accidentally exposed in logs or configuration files
+- Exposed in logs or configuration files
 - Compromised and used persistently until manually revoked
 - Difficult to manage and rotate
 
-OIDC-based publishing uses short-lived, cryptographically-signed tokens that are specific to your workflow and cannot be extracted or reused.
+OIDC-based publishing uses short-lived, cryptographically signed tokens that are specific to your workflow and can't be extracted or reused.
 
 ### Prerequisites
 
@@ -405,10 +405,10 @@ This is the easiest path if you can upgrade to version 3.12.0 or later of the Ty
 
 <Accordion title="Path 2: Manual CI workflow update">
 
-Use this path if you cannot upgrade the generator or have customized your CI workflow.
+Use this path if you can't upgrade the generator or have customized your CI workflow.
 
 **When to use this path:**
-- You cannot upgrade due to breaking changes or bugs
+- You can't upgrade due to breaking changes or bugs
 - You've customized your CI workflow and added it to `.fernignore`
 - Path 1 didn't update your workflow file
 
@@ -506,7 +506,7 @@ Use this path if you cannot upgrade the generator or have customized your CI wor
 
 After completing either migration path:
 
-1. **Trigger a workflow run** by creating a GitHub release with an alpha tag (e.g., `v1.0.0-alpha`)
+1. **Trigger a workflow run** by creating a GitHub release with an alpha tag (for example, `v1.0.0-alpha`)
 2. **Check the workflow logs** to verify the publish step succeeds
 3. **Verify provenance** by visiting your package on [npmjs.com](https://npmjs.com) - you should see a provenance badge