oxlint honors ESLint disable comments, but only with its namespaced rule id

oxlint is not ESLint and reads no .eslintrc, but it still respects ESLint-style suppression comments. This matters if you migrate a codebase from ESLint and want to know whether your existing comments keep working.

### Repro

1. Make a project with only `oxlint` installed. No ESLint, no ESLint config. 2. Write code that oxlint flags, for example a React hook with a missing dependency, which triggers `react-hooks/exhaustive-deps`. 3. Run `npx oxlint`. The warning shows up. 4. Add this comment on the line directly above the flagged line:

``` // eslint-disable-next-line react-hooks/exhaustive-deps ```

5. Run `npx oxlint` again. The warning is gone.

The same applies to the trailing form, `// eslint-disable-line`, placed on the flagged line itself. Both silence the warning even though no ESLint is installed.

### The rule name has to match

The rule id in the comment must be oxlint's namespaced id. `react-hooks/exhaustive-deps` works. A bare `exhaustive-deps` is not the same id, so don't write it that way and expect it to suppress anything. If a suppression comment seems to do nothing, check the rule name in the comment against the id printed in the oxlint output before you suspect anything else.

### What this means in practice

- Existing `eslint-disable-next-line` and `eslint-disable-line` comments carry over to oxlint without being rewritten, as long as the rule ids are the namespaced ones. - You do not need an `oxlint-disable` variant to get suppression working in a project that has only oxlint. - The comments are keyed by rule id, so they stay tied to the specific rule you meant to silence.

I did not test other comment forms here, such as block-level `eslint-disable` / `eslint-enable` pairs, so I make no claim about them. The two line-level forms above are the ones I reproduced.

The repro takes under a minute and needs nothing but oxlint, so it is easy to confirm on your own machine before relying on it.