docs: update stale links to latest (#12313)

Author: lumirlumir

docs/troubleshooting/faqs/ESLint.mdx

@@ -113,7 +113,7 @@ Two common solutions in TypeScript for declaring the existence of a global varia
 [Using global variables is generally discouraged](https://stackoverflow.com/questions/10525582/why-are-global-variables-considered-bad-practice).
 If possible, it's best to avoid declaring globals altogether.
 
-If you absolutely must use one of the two strategies, then you can use an [ESLint configuration comment](https://eslint.org/docs/latest/use/configure/rules#using-configuration-comments-1) to disable rules as needed.
+If you absolutely must use one of the two strategies, then you can use an [ESLint configuration comment](https://eslint.org/docs/latest/use/configure/rules#use-configuration-comments) to disable rules as needed.
 For example:
 
 ```ts

packages/eslint-plugin/docs/rules/README.md

@@ -58,7 +58,7 @@ module.exports = {
 
 ## Frozen Rules
 
-When rules are feature complete, they are marked as frozen (indicated with ❄️ in the documentation). This applies to standalone rules that are complete, as well as [extension rules](#extension-rules) whose underlying core ESLint rules are frozen. After that point, we expect users to use [disable comments](https://eslint.org/docs/latest/use/configure/rules#using-configuration-comments-1) when they find an edge case that isn’t covered.
+When rules are feature complete, they are marked as frozen (indicated with ❄️ in the documentation). This applies to standalone rules that are complete, as well as [extension rules](#extension-rules) whose underlying core ESLint rules are frozen. After that point, we expect users to use [disable comments](https://eslint.org/docs/latest/use/configure/rules#use-configuration-comments) when they find an edge case that isn’t covered.
 
 When a rule is frozen, it means:
 

packages/eslint-plugin/docs/rules/adjacent-overload-signatures.mdx

@@ -11,7 +11,7 @@ import TabItem from '@theme/TabItem';
 
 Function overload signatures represent multiple ways a function can be called, potentially with different return types.
 It's typical for an interface or type alias describing a function to place all overload signatures next to each other.
-If Signatures placed elsewhere in the type are easier to be missed by future developers reading the code.
+If signatures placed elsewhere in the type are easier to be missed by future developers reading the code.
 
 ## Examples
 
@@ -98,7 +98,7 @@ export function foo(sn: string | number): void;
 
 It can sometimes be useful to place overload signatures alongside other meaningful parts of a type.
 For example, if each of a function's overloads corresponds to a different property, you might wish to put each overloads next to its corresponding property.
-You might consider using [ESLint disable comments](https://eslint.org/docs/latest/use/configure/rules#using-configuration-comments-1) for those specific situations instead of completely disabling this rule.
+You might consider using [ESLint disable comments](https://eslint.org/docs/latest/use/configure/rules#use-configuration-comments) for those specific situations instead of completely disabling this rule.
 
 ## Related To
 

packages/eslint-plugin/docs/rules/await-thenable.mdx

@@ -181,4 +181,4 @@ async function shouldAwait() {
 If you want to allow code to `await` non-Promise values.
 For example, if your framework is in transition from one style of asynchronous code to another, it may be useful to include `await`s unnecessarily.
 This is generally not preferred but can sometimes be useful for visual consistency.
-You might consider using [ESLint disable comments](https://eslint.org/docs/latest/use/configure/rules#using-configuration-comments-1) for those specific situations instead of completely disabling this rule.
+You might consider using [ESLint disable comments](https://eslint.org/docs/latest/use/configure/rules#use-configuration-comments) for those specific situations instead of completely disabling this rule.

packages/eslint-plugin/docs/rules/ban-ts-comment.mdx

@@ -158,7 +158,7 @@ if (false) {
 ## When Not To Use It
 
 If your project or its dependencies were not architected with strong type safety in mind, it can be difficult to always adhere to proper TypeScript semantics.
-You might consider using [ESLint disable comments](https://eslint.org/docs/latest/use/configure/rules#using-configuration-comments-1) for those specific situations instead of completely disabling this rule.
+You might consider using [ESLint disable comments](https://eslint.org/docs/latest/use/configure/rules#use-configuration-comments) for those specific situations instead of completely disabling this rule.
 
 ## Further Reading
 

packages/eslint-plugin/docs/rules/class-methods-use-this.mdx

@@ -132,4 +132,4 @@ class Derived implements Base {
 ## When Not To Use It
 
 If your project dynamically changes `this` scopes around in a way TypeScript has difficulties modeling, this rule may not be viable to use.
-You might consider using [ESLint disable comments](https://eslint.org/docs/latest/use/configure/rules#using-configuration-comments-1) for those specific situations instead of completely disabling this rule.
+You might consider using [ESLint disable comments](https://eslint.org/docs/latest/use/configure/rules#use-configuration-comments) for those specific situations instead of completely disabling this rule.

packages/eslint-plugin/docs/rules/consistent-type-definitions.mdx

@@ -125,7 +125,7 @@ However, keep in mind that inconsistent style can harm readability in a project.
 We recommend picking a single option for this rule that works best for your project.
 
 You might occasionally need to a different definition type in specific cases, such as if your project is a dependency or dependent of another project that relies on a specific type definition style.
-Consider using [ESLint disable comments](https://eslint.org/docs/latest/use/configure/rules#using-configuration-comments-1) for those specific situations instead of completely disabling this rule.
+Consider using [ESLint disable comments](https://eslint.org/docs/latest/use/configure/rules#use-configuration-comments) for those specific situations instead of completely disabling this rule.
 
 ## Further Reading
 

packages/eslint-plugin/docs/rules/no-duplicate-enum-values.mdx

@@ -61,6 +61,6 @@ enum E {
 
 It can sometimes be useful to include duplicate enum members for very specific use cases.
 For example, when renaming an enum member, it can sometimes be useful to keep the old name until a scheduled major breaking change.
-You might consider using [ESLint disable comments](https://eslint.org/docs/latest/use/configure/rules#using-configuration-comments-1) for those specific situations instead of completely disabling this rule.
+You might consider using [ESLint disable comments](https://eslint.org/docs/latest/use/configure/rules#use-configuration-comments) for those specific situations instead of completely disabling this rule.
 
 In general, if your project intentionally duplicates enum member values, you can avoid this rule.

packages/eslint-plugin/docs/rules/no-duplicate-type-constituents.mdx

@@ -80,7 +80,7 @@ When set to true, duplicate checks on union type constituents are ignored.
 ## When Not To Use It
 
 It can sometimes be useful for the sake of documentation to include aliases for the same type.
-You might consider using [ESLint disable comments](https://eslint.org/docs/latest/use/configure/rules#using-configuration-comments-1) for those specific situations instead of completely disabling this rule.
+You might consider using [ESLint disable comments](https://eslint.org/docs/latest/use/configure/rules#use-configuration-comments) for those specific situations instead of completely disabling this rule.
 
 > In some of those cases, [branded types](https://basarat.gitbook.io/typescript/main-1/nominaltyping#using-interfaces) might be a type-safe way to represent the underlying data types.
 

packages/eslint-plugin/docs/rules/no-dynamic-delete.mdx

@@ -58,7 +58,7 @@ delete container['Infinity'];
 ## When Not To Use It
 
 When you know your keys are safe to delete, this rule can be unnecessary.
-You might consider using [ESLint disable comments](https://eslint.org/docs/latest/use/configure/rules#using-configuration-comments-1) for those specific situations instead of completely disabling this rule.
+You might consider using [ESLint disable comments](https://eslint.org/docs/latest/use/configure/rules#use-configuration-comments) for those specific situations instead of completely disabling this rule.
 
 Do not consider this rule as performance advice before profiling your code's bottlenecks.
 Even repeated minor performance slowdowns likely do not significantly affect your application's general perceived speed.