Fix broken links related to the new "Trusted publishing" page (#1690)

<!-- What / Why -->
<!-- Describe the request in detail. What it does and why it's being
changed. -->

The internal links added in
#1674 followed the on-disk
paths and did not respect that the URL paths use a different scheme, as
explained in
https://github.com/npm/documentation/blob/4c574b89e23515d8411e5ec52624d6a932b874e0/CONTRIBUTING.md#urls:

> ### URLs
> Note that for backward compatibility reasons, the on-disk paths are
not precisely identical to the URLs for the documentation. To keep URLs
expressive but still short, intermediate directories are removed from a
page's URL.
>
> (...)
>
> You might (understandably) expect the page "Creating Node.js modules"
to be URL-wise beneath `contributing-packages-to-the-registry`, but
unfortunately, you would be wrong. To keep URLs short, the intermediate
folder paths are removed from pages, so "Creating Node.js modules"
becomes `https://docs.npmjs.com/creating-node-js-modules`.

Also see
https://github.com/npm/documentation/blob/4c574b89e23515d8411e5ec52624d6a932b874e0/CONTENT-MODEL.md#content-structure:

> ## Content structure
> 
> Docs are grouped by topic.
> 
> - Top-level doc set (Example:
https://docs.npmjs.com/packages-and-modules)
> - Categories (Example:
https://docs.npmjs.com/packages-and-modules/introduction-to-packages-and-modules)
> - **Articles (Example:
https://docs.npmjs.com/about-packages-and-modules)**

As a result, these links did not work at https://docs.npmjs.com/. This
PR fixes them.

## References

Related to #1674 (all links
fixed in this PR were introduced there)

<!-- Examples:
  Related to #0
  Depends on #0
  Blocked by #0
  Fixes #0
  Closes #0
-->

Author: generalmimon

content/integrations/integrating-npm-with-external-services/creating-and-viewing-access-tokens.mdx

@@ -12,7 +12,7 @@ You can [create](#creating-access-tokens) and [view](#viewing-access-tokens) acc
 
 <Note>
 
-**Note:** For greater security, we recommend using [granular access tokens](#creating-granular-access-tokens-on-the-website) instead of legacy read-only tokens or legacy automation tokens. For CI/CD workflows, consider using [trusted publishing](/packages-and-modules/securing-your-code/trusted-publishers), which eliminates the need for long-lived tokens entirely.
+**Note:** For greater security, we recommend using [granular access tokens](#creating-granular-access-tokens-on-the-website) instead of legacy read-only tokens or legacy automation tokens. For CI/CD workflows, consider using [trusted publishing](/trusted-publishers), which eliminates the need for long-lived tokens entirely.
 
 </Note>
 
@@ -29,7 +29,7 @@ You can [create](#creating-access-tokens) and [view](#viewing-access-tokens) acc
 4. Select the type of access token:
    - **Read-only**: A read-only token can only be used to download packages from the registry. It will have permission to read any private package that you have access to. This is recommended for automation and workflows where you are installing packages, but not publishing new ones.
 
-   - **Automation**: An automation token can download packages and publish new ones, but if you have two-factor authentication (2FA) configured on your account, it will **not** be enforced. You can use an automation token in continuous integration workflows and other automation systems to publish a package even when you cannot enter a one-time passcode. For enhanced security in CI/CD workflows, consider using [trusted publishing](/packages-and-modules/securing-your-code/trusted-publishers) instead, which eliminates the need for long-lived tokens.
+   - **Automation**: An automation token can download packages and publish new ones, but if you have two-factor authentication (2FA) configured on your account, it will **not** be enforced. You can use an automation token in continuous integration workflows and other automation systems to publish a package even when you cannot enter a one-time passcode. For enhanced security in CI/CD workflows, consider using [trusted publishing](/trusted-publishers) instead, which eliminates the need for long-lived tokens.
 
    - **Publish**: A publish token can perform any action on your behalf, including downloading packages, publishing packages, and changing user settings or package settings. If you have two-factor authentication configured on your account, you will be required to enter a one-time passcode when using a publish token. This is recommended for interactive workflows such as a CLI.
 

content/integrations/integrating-npm-with-external-services/using-private-packages-in-a-ci-cd-workflow.mdx

@@ -8,7 +8,7 @@ You can use access tokens to test private npm packages with continuous integrati
 
 ## Recommended: Use trusted publishing for package publishing
 
-For publishing packages from CI/CD workflows, we recommend using [trusted publishing](/packages-and-modules/securing-your-code/trusted-publishers) instead of access tokens. Trusted publishing uses OpenID Connect (OIDC) to provide secure publishing that eliminates the security risks associated with long-lived tokens.
+For publishing packages from CI/CD workflows, we recommend using [trusted publishing](/trusted-publishers) instead of access tokens. Trusted publishing uses OpenID Connect (OIDC) to provide secure publishing that eliminates the security risks associated with long-lived tokens.
 
 Trusted publishing is supported for:
 
@@ -35,7 +35,7 @@ For more information on creating access tokens, including CIDR-whitelisted token
 
 ### Continuous deployment
 
-For publishing packages in continuous deployment environments, we strongly recommend using [trusted publishing](/packages-and-modules/securing-your-code/trusted-publishers) when available, as it provides enhanced security without requiring token management.
+For publishing packages in continuous deployment environments, we strongly recommend using [trusted publishing](/trusted-publishers) when available, as it provides enhanced security without requiring token management.
 
 If trusted publishing is not available for your CI/CD provider, you may create an [automation token][create-token] on the website. This will allow you to publish even if you have two-factor authentication enabled on your account.
 

content/packages-and-modules/contributing-packages-to-the-registry/creating-and-publishing-unscoped-public-packages.mdx

@@ -72,7 +72,7 @@ npm install path/to/my-package
 
    <Note>
 
-   **Note:** If you use GitHub Actions or GitLab CI/CD to publish your packages, consider using [trusted publishing](/packages-and-modules/securing-your-code/trusted-publishers) for enhanced security. Trusted publishing automatically generates provenance information and eliminates the need for access tokens in your CI/CD workflows. For more information, see "[Generating provenance statements][provenance-how-to]."
+   **Note:** If you use GitHub Actions or GitLab CI/CD to publish your packages, consider using [trusted publishing](/trusted-publishers) for enhanced security. Trusted publishing automatically generates provenance information and eliminates the need for access tokens in your CI/CD workflows. For more information, see "[Generating provenance statements][provenance-how-to]."
 
    </Note>
 

content/packages-and-modules/securing-your-code/generating-provenance-statements.mdx

@@ -42,7 +42,7 @@ Before you can publish your packages with provenance, you must:
   - GitHub Actions. For more information, see "[Publishing packages with provenance via GitHub Actions][github-provenance]."
   - GitLab CI/CD. For more information, see "[Publishing packages with provenance via GitLab CI/CD][gitlab-provenance]."
 
-**Note:** If you use [trusted publishing](/packages-and-modules/securing-your-code/trusted-publishers), provenance attestations are automatically generated for your packages without requiring the `--provenance` flag. This provides enhanced security and eliminates the need for access tokens in your CI/CD workflows.
+**Note:** If you use [trusted publishing](/trusted-publishers), provenance attestations are automatically generated for your packages without requiring the `--provenance` flag. This provides enhanced security and eliminates the need for access tokens in your CI/CD workflows.
 
 ## Publishing packages with provenance via GitHub Actions
 

content/packages-and-modules/securing-your-code/requiring-2fa-for-package-publishing-and-settings-modification.mdx

@@ -8,7 +8,7 @@ To protect your packages, as a package publisher, you can require everyone who h
 
 You may also choose to allow publishing with either two-factor authentication _or_ with [automation tokens][creating-automation-token]. This lets you configure automation tokens in a CI/CD workflow, but requires two-factor authentication from interactive publishes.
 
-For CI/CD workflows, consider using [trusted publishing](/packages-and-modules/securing-your-code/trusted-publishers), which provides secure, token-free publishing that automatically enforces strong authentication without requiring manual token management.
+For CI/CD workflows, consider using [trusted publishing](/trusted-publishers), which provides secure, token-free publishing that automatically enforces strong authentication without requiring manual token management.
 
 ## Configuring two-factor authentication
 

content/packages-and-modules/securing-your-code/trusted-publishers.mdx

@@ -228,7 +228,7 @@ While trusted publishing handles the publish operation, you may still need authe
 - run: npm publish
 ```
 
-Always use [read-only granular access tokens](/integrations/integrating-npm-with-external-services/creating-and-viewing-access-tokens#creating-granular-access-tokens-on-the-website) for installing dependencies. This limits potential damage if the token is ever compromised.
+Always use [read-only granular access tokens](/creating-and-viewing-access-tokens#creating-granular-access-tokens-on-the-website) for installing dependencies. This limits potential damage if the token is ever compromised.
 
 ### Additional security measures