Describe the bug

The new ESLint flat config allows assigning any arbitrary prefix you want for rule names. The prefix used in the plugins object:

...is then what the rules are referred to as in rules:

Steps to reproduce

1. import { tanstackConfig } from '@tanstack/config/eslint' in an eslint.config.js
2. See that rules have names like ts/array-type, not @typescript-eslint/array-type

Expected behavior

The recommended preset configs from typescript-eslint use a '@typescript-eslint/' prefix, not 'ts/'. So if you try to, say, use both @tanstack/config/eslint and typescript-eslint in a config:

import { tanstackConfig } from '@tanstack/config/eslint'
import tseslint from 'typescript-eslint';

export default [
  ...tanstackConfig,
  { 
    rules: {
      'ts/no-explicit-any': 'error', // (just as an example)
    },
  },
  ...tseslint.configs.recommended,
]

...you'll get each rule running and reporting twice:

$ pnpm run test:eslint

...

   ✖  nx run @tanstack/form-core:test:eslint
      > @tanstack/form-core@0.25.2 test:eslint /Users/josh/repos/tanstack-form/packages/form-core
      > eslint ./src ./tests
      
      
      /Users/josh/repos/tanstack-form/packages/form-core/src/FieldApi.ts
        418:13  error  Unexpected any. Specify a different type  ts/no-explicit-any
        418:13  error  Unexpected any. Specify a different type  @typescript-eslint/no-explicit-any
      ...

Change request: can we switch the prefix to '@typescript-eslint/'?

How often does this bug happen?

Every time

Screenshots or Videos

No response

TanStack Config version

0.9.2

TypeScript version

No response

Additional context

I realize the ts/ prefix is much easier to read+write than the super verbose @typescript-eslint/. But we're stuck with @typescript-eslint/ in typescript-eslint because that's what everyone's been using for years.

We in typescript-eslint have previously surfaced feedback to ESLint core that prefix duplication is a known user pain: eslint/eslint#17766. But there isn't a way to lock down and/or deduplicate the prefixes (yet?).

Keeping to the standard prefix makes it easier to use standard shared configs: #114.