ci(docs): validate docs.json and redirect destinations

[palango]

CI ran mintlify broken-links without its redirect option, so nothing checked the redirects array in docs.json: a destination could point at a missing page or at /, and a duplicate source failed the job only indirectly, as about 100 unrelated broken links. This adds mintlify validate as the first step and turns on --check-redirects, both existing Mintlify CLI features, so the three cases #1846 asks about are covered without a custom script.

The PR is stacked on #2328. On main, broken-links --check-redirects fails on the 9 redirects that point at /, and #2328 re-points them. The workflow only runs for PRs into main, so the checks start here once #2328 merges and GitHub retargets this PR.

What each step catches

Tested with mintlify 4.2.910, the version npx installs in CI:

Defect	Caught by
Duplicate redirect source	mintlify validate: "Each source path can only be used once", exit 1
Destination that is not a page, including /	broken-links --check-redirects
Destination that is itself a redirect source	nothing (there are none today)
#anchor in a destination	nothing

$ npx mintlify validate                          # this branch
success build validation passed
$ npx mintlify broken-links --check-redirects    # this branch
success no broken links found
$ npx mintlify broken-links --check-redirects    # origin/main
found 9 broken links in 1 files

Dropped from #1846

The issue also asked to keep the redirects sorted alphabetically. It was written against the Docusaurus _redirects file, which #2040 removed. In Mintlify an exact source beats any :slug* wildcard wherever it sits in the array, and order only matters between two wildcards. No wildcard today sits inside another's prefix, so a sort buys nothing, and it would make every insertion a large diff. Tested in mint dev and against production.

Closes #1846.

[GigaHierz]

Approving. Note for the record: this PR was briefly closed when I merged #2328 with --delete-branch — deleting the base branch closes a stacked PR rather than retargeting it. I restored the ref, reopened, and retargeted to main. After update-branch the diff reconciles down to the workflow file alone, which is the intended end state.

Verified the new checks pass against current main:

$ npx mintlify@4.2.910 validate
success build validation passed
$ npx mintlify@4.2.910 broken-links --check-redirects
success no broken links found

So this turns on without an immediate red build, which only holds because #2328 landed first.

Two things I checked that are easy to get wrong:

• The required status check context is the job name (Check for broken links), and this diff only renames steps. The context is unchanged, so the branch ruleset keeps matching and no protection update is needed.
• Ordering validate before broken-links is the right call and the comment explains why: a duplicate redirect source otherwise surfaces as ~100 unrelated broken links, which is exactly the failure mode that makes people ignore the job.

Closes #1846.