feat(linter): Add eslint/no-unresolved rule

[cap10morgan]

This adds a basic version of the eslint no-unresolved rule: https://github.com/import-js/eslint-plugin-import/blob/main/docs/rules/no-unresolved.md

[Copilot]

Pull request overview

This PR implements a basic version of the eslint-plugin-import no-unresolved rule to detect unresolved module imports. The rule checks that all imported modules can be resolved, with support for CommonJS, AMD, and ES modules.

Changes:

• Adds a new no_unresolved rule with configuration options for CommonJS, AMD, ignore patterns, and case sensitivity
• Implements module resolution checking for import statements and require/define calls
• Adds test fixtures and snapshot tests for various import scenarios

Reviewed changes

Copilot reviewed 5 out of 5 changed files in this pull request and generated 3 comments.

File	Description
crates/oxc_linter/src/rules/import/no_unresolved.rs	Core rule implementation with import checking logic and configuration
crates/oxc_linter/src/rules.rs	Registers the new rule in the linter module system
crates/oxc_linter/src/snapshots/*.snap	Test snapshots for basic and node-protocol test scenarios

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[connorshea]

It should be noted that we had this rule at one point in the past, but it was deemed too difficult to make accurate, and so marked as an unsupported rule:

oxc/tasks/lint_rules/src/unsupported-rules.json

Line 8 in f804636

"import/no-unresolved": "Will always contain false positives due to module resolution complexity.",

I am unsure if that has really changed enough to warrant implementing support for the rule. But I'll defer to the other maintainers' opinions.

Also, you should use the rulegen tool (just new-rule) for generating a new rule, it'll pull in tests and such from the original rule (well, for plugins that have a sensible structure that we can understand, it will). https://oxc.rs/docs/contribute/linter/adding-rules.html