Currently, we render diagnostics with the eslint-plugin- prefix in them, like:

  ⚠ eslint-plugin-unicorn(prefer-date-now): Prefer `Date.now()` over `new Date().getTime()`
   ╭─[prefer_date_now.tsx:1:12]
 1 │ const ts = (new Date).getTime();
   ·            ────────────────────
   ╰────
  help: Change to `Date.now()`.

I think this was initially helpful when oxlint rules were aiming to be exactly 1:1 with oxlint and didn't support JS plugins at all. However, it's more confusing now that you can run the actual ESLint rules as a JS plugin. It might be less clear that it's not the actual ESLint plugin, but a built-in rule instead.

In some cases, we've also differentiated ourselves from the ESLint behavior, so it doesn't really make sense to call it exactly the same rule as from the ESLint plugin. I think we also have a strong enough identity as this point that we don't need to tie ourselves to ESLint beyond the rule names and plugin names.

I would propose that we just shorten it so it uses the canonical rule name and plugin names like:

  ⚠ unicorn(prefer-date-now): Prefer `Date.now()` over `new Date().getTime()`
   ╭─[prefer_date_now.tsx:1:12]
 1 │ const ts = (new Date).getTime();
   ·            ────────────────────
   ╰────
  help: Change to `Date.now()`.

It's shorter, more clear, and reduces our ties to ESLint.