fix(docs): finish bare-relative link conversion + add lint guardrail

Copilot flagged two stragglers on editors.md where the previous
file-by-file conversion stopped halfway. Sweeping for the same
pattern across the active content tree found 76 bare relative
internal links total — 14 in this PR's already-modified files
(Copilot's two plus twelve more) and 62 in unchanged files.

Why the build doesn't catch this
─────────────────────────────────
`onBrokenLinks: 'throw'` (set in this PR) only validates *file-based*
markdown references — links whose URL ends in `.md` / `.mdx`. Those
go through Docusaurus's file resolver, which can prove the target
exists. Bare relative URL paths like `[Foo](../foo)` skip that
resolver entirely; Docusaurus emits them as raw hrefs. The browser
then resolves them against the *current* page URL, and for
trailing-slash routes that almost always lands in the wrong
directory. Page navigates client-side and 404s. The linkinator job
in CI *can* catch these, but it's `continue-on-error: true` so
findings are advisory.

What this commit does
──────────────────────
1. Fix all 76 bare relative internal links across the active docs
   tree by appending `.md` to each one (preserving anchors / query
   strings). All 76 targets resolved to real files; no link
   targets changed, only the form of the reference.

2. Fix the component-page generator. 54 of the 76 bare links lived
   in two auto-generated index files (`components/ui/index.mdx`
   and `components/design-system/index.mdx`). The next regeneration
   would have undone the manual fixes without this. The two
   emission sites in `generate-superset-components.mjs` now emit
   `.md`-suffixed links; comment at the call site explains why.

3. Add `docs/scripts/lint-docs-links.mjs` — fast source-level
   linter that scans `.md`/`.mdx` files under the active content
   trees (skipping `versioned_docs/` snapshots) and fails if it
   finds any markdown link whose URL starts with `./` or `../` and
   does not end in `.md`/`.mdx`. Excludes asset paths (.png,
   .json, etc.) and ignores fenced code blocks. Wired up as
   `yarn lint:docs-links`.

4. Add a `Lint docs links` step to `superset-docs-verify.yml`,
   running before the build step so PRs that introduce the pattern
   fail in seconds rather than at build-time / not at all. Blocking,
   not advisory — exactly the gap linkinator's `continue-on-error`
   leaves open.

Verified
────────
- `yarn lint:docs-links` exits 0 on the cleaned tree
- Re-introducing one bare link makes the linter report the exact
  file:line with the offending URL, exit code 1
- All 76 originally-flagged targets resolved to real `.md` / `.mdx`
  files; only the form of the reference changed

docs/developer_docs/guidelines/backend-style-guidelines.md

@@ -114,7 +114,7 @@ class CreateDashboardCommand(BaseCommand):
 
 ### Data Access Objects (DAOs)
 
-See: [DAO Style Guidelines and Best Practices](./backend/dao-style-guidelines)
+See: [DAO Style Guidelines and Best Practices](./backend/dao-style-guidelines.md)
 
 ## Testing
 

docs/developer_docs/guidelines/frontend-style-guidelines.md

@@ -29,16 +29,16 @@ This is a list of statements that describe how we do frontend development in Sup
 - We develop using TypeScript.
   - See: [SIP-36](https://github.com/apache/superset/issues/9101)
 - We use React for building components, and Redux to manage app/global state.
-  - See: [Component Style Guidelines and Best Practices](./frontend/component-style-guidelines)
+  - See: [Component Style Guidelines and Best Practices](./frontend/component-style-guidelines.md)
 - We prefer functional components to class components and use hooks for local component state.
 - We use [Ant Design](https://ant.design/) components from our component library whenever possible, only building our own custom components when it's required.
   - See: [SIP-48](https://github.com/apache/superset/issues/11283)
 - We use [@emotion](https://emotion.sh/docs/introduction) to provide styling for our components, co-locating styling within component files.
   - See: [SIP-37](https://github.com/apache/superset/issues/9145)
-  - See: [Emotion Styling Guidelines and Best Practices](./frontend/emotion-styling-guidelines)
+  - See: [Emotion Styling Guidelines and Best Practices](./frontend/emotion-styling-guidelines.md)
 - We use Jest for unit tests, React Testing Library for component tests, and Cypress for end-to-end tests.
   - See: [SIP-56](https://github.com/apache/superset/issues/11830)
-  - See: [Testing Guidelines and Best Practices](../testing/testing-guidelines)
+  - See: [Testing Guidelines and Best Practices](../testing/testing-guidelines.md)
 - We add tests for every new component or file added to the frontend.
 - We organize our repo so similar files live near each other, and tests are co-located with the files they test.
   - See: [SIP-61](https://github.com/apache/superset/issues/12098)
@@ -46,6 +46,6 @@ This is a list of statements that describe how we do frontend development in Sup
 - We use OXC (oxlint) and Prettier to automatically fix lint errors and format the code.
   - We do not debate code formatting style in PRs, instead relying on automated tooling to enforce it.
   - If there's not a linting rule, we don't have a rule!
-  - See: [Linting How-Tos](../contributing/howtos#typescript--javascript)
+  - See: [Linting How-Tos](../contributing/howtos.md#typescript--javascript)
 - We use [React Storybook](https://storybook.js.org/) to help preview/test and stabilize our components
   - A public Storybook with components from the `master` branch is available [here](https://apache-superset.github.io/superset-ui/?path=/story/*)

docs/developer_docs/guidelines/frontend/component-style-guidelines.md

@@ -53,7 +53,7 @@ superset-frontend/src/components
 
 **Storybook:** Components should come with a storybook file whenever applicable, with the following naming convention `\{ComponentName\}.stories.tsx`. More details about Storybook below
 
-**Unit and end-to-end tests:** All components should come with unit tests using Jest and React Testing Library. The file name should follow this naming convention `\{ComponentName\}.test.tsx`. Read the [Testing Guidelines and Best Practices](../../testing/testing-guidelines) for more details
+**Unit and end-to-end tests:** All components should come with unit tests using Jest and React Testing Library. The file name should follow this naming convention `\{ComponentName\}.test.tsx`. Read the [Testing Guidelines and Best Practices](../../testing/testing-guidelines.md) for more details
 
 **Reference naming:** Use `PascalCase` for React components and `camelCase` for component instances