[Bug]: docs i18n parity is broken on main (48 violations) and the repo's own parity script runs in no workflow

What happened?

scripts/check-docs-i18n-parity.sh shipped with the i18n PR #1693 and is named in DOCS_I18N.md as the verification step for any docs translation work. It exits 1 on current main with 48 violations, and it is referenced by no workflow, so nothing has caught the drift.

Verified against main @ e82686860.

Proof

$ sh scripts/check-docs-i18n-parity.sh; echo "exit=$?"
DOCS I18N PARITY FAILURES (48):
  zh: nav entry not localized (English fallback): integrations/overview
  zh: nav entry not localized (English fallback): integrations/clerk
  ...
  zh: missing translation of deployment/self-host-storage
exit=1

$ grep -rn "check-docs-i18n-parity" .github/
(no matches)

lint-and-format.yml runs scripts/sync-skills.sh --check and sh scripts/check-setup-sh.sh, but not this one. None of the other seven workflows reference it either.

The 48 split into two classes over the same eight pages:

24 — localized navs carry un-prefixed English paths. All three of zh, zh-Hant and es list integrations/overview, integrations/clerk, integrations/auth0, integrations/workos, integrations/kinde, integrations/stytch, integrations/better-auth and deployment/self-host-storage without a locale prefix. The script's own comment calls this out as the thing it exists to prevent: "no silent English fallback masking a missing translation".

24 — those eight English pages have no translated file in any locale. All eight exist as docs/<path>.mdx; none of docs/zh/, docs/zh-Hant/ or docs/es/ has a counterpart.

Live site confirms the second half:

https://docs.insforge.dev/integrations/clerk              -> 200
https://docs.insforge.dev/zh/integrations/clerk           -> 404
https://docs.insforge.dev/deployment/self-host-storage    -> 200
https://docs.insforge.dev/zh/deployment/self-host-storage -> 404

Why it matters

A reader browsing in 中文 or Español sees these eight entries in the sidebar and gets English content, with nothing indicating a translation is missing. Every locale-prefixed URL for them 404s, so any link or language-switch that builds the localized path lands on a dead page rather than degrading to English.

The second-order cost is the bigger one: DOCS_I18N.md tells contributors to run this script to verify their work, so the first person to follow that instruction gets 48 pre-existing failures with no way to tell which are theirs. A gate that is already red teaches people to ignore it.

Root cause

Two separate things, one consequence.

1. The script was written and documented but never wired into CI, so the invariant was only ever enforced by whoever remembered to run it locally.
2. Eight English pages were added to the localized navs without translations behind them. snippets/* are correctly excluded, since DOCS_I18N.md states they are deliberately not localized and the script only walks nav pages, so this is not that case.

Proposed fix

Two commits, in this order, so the gate is green when it starts running:

1. Resolve the 48. Either translate the eight pages into all three locales, or drop them from the zh/zh-Hant/es nav blocks until translations exist. Dropping them is the smaller change and matches how the other untranslated pages are already handled.
2. Add the check to lint-and-format.yml next to the two script checks already there:

- name: Check docs i18n parity
  run: sh scripts/check-docs-i18n-parity.sh

Adjacent but distinct: PR #1894 fixes in-body links to self-host-storage inside six localized deploy guides. That is a different surface from the nav entries and the missing files here, and it does not change this script's result.

Acceptance criteria

• sh scripts/check-docs-i18n-parity.sh exits 0 on main.
• No zh/zh-Hant/es nav entry points at an un-prefixed English path.
• Every page in the English nav either has a file in all three locales or is absent from all three localized navs.
• lint-and-format runs the script, so a PR that adds an English nav page without translations fails before merge.

Note on claiming

I am at the three-issue cap (#1916, #1835, #1685) so I cannot claim this. Happy to take it if a slot is freed or it is assigned to me; otherwise it is fully specified for anyone.