build(eslint-config-fluid): migrate @rushstack/no-new-null to @typescript-eslint/no-restricted-types

[tylerbutler]

Replace the Rushstack rule with the equivalent TypeScript ESLint rule
as recommended by the TypeScript ESLint migration guide.

Blocked by

• build(eslint-config-fluid): migrate from eslint-plugin-import to eslint-plugin-import-x #25661 (migrate import plugin)
• build(eslint-config-fluid): migrate to @eslint-community/eslint-plugin-eslint-comments #25662 (migrate eslint-comments)
• build(eslint-config-fluid): update @typescript-eslint to v8 #25663 (update TypeScript ESLint)

Blocking

• build(eslint-config-fluid): update minor dependencies #25665 (update minor dependencies)
• build(eslint-config-fluid): remove unused Rushstack plugins #25666 (remove Rushstack plugins)

[Copilot]

Pull Request Overview

This PR migrates from the Rushstack ESLint plugin rule @rushstack/no-new-null to the equivalent TypeScript ESLint rule @typescript-eslint/no-restricted-types as part of a broader effort to migrate away from Rushstack plugins. The migration maintains the same functionality of preventing the use of null in favor of undefined.

• Replaces @rushstack/no-new-null with @typescript-eslint/no-restricted-types configured to restrict null usage
• Updates both the recommended and minimal-deprecated ESLint configurations
• Maintains the same error/warning levels and provides equivalent functionality with auto-fix support

Reviewed Changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated no comments.

File	Description
common/build/eslint-config-fluid/recommended.js	Migrates the rule from Rushstack to TypeScript ESLint with "error" severity
common/build/eslint-config-fluid/minimal-deprecated.js	Migrates the rule from Rushstack to TypeScript ESLint with "warn" severity and updates documentation

[alexvy86]

Only quick glance so far: I see several new disables. Double checking that they are legit new hits, like we know can happen from more up-to-date rules, and not copilot pattern-matching on places that might have had a package-level disable or similar?

[tylerbutler]

Only quick glance so far: I see several new disables. Double checking that they are legit new hits, like we know can happen from more up-to-date rules, and not copilot pattern-matching on places that might have had a package-level disable or similar?

Good question. The old rushstack no-new-null rule apparently is not as sensitive as the replacement rule. At first I thought that was a good thing, but because we have so many types that go over the wire, we have a lot of legitimate null usage.

Anyway, I originally thought the rushstack replacement was needed because it wasn't compatible with eslint9. But I was wrong about that, so I am leaning towards just upgrading it and postponing any further related work.