consider consolidation of tooling, revise ts setup

Is your feature request related to a problem? Please describe.
A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]

I took a pass at consolidating the package manager usage based on the information in the contributing.md doc, but there's a few other areas I noticed that would benefit from further consolidation. I wanted to file an issue to first discuss the proposed changes in order to better understand the decisions made before opening a PR that clobbers an intentional decision 🙂

Happy to put up a PR for each of the following items!

Describe the solution you'd like
A clear and concise description of what you want to happen.

1. remove compilerOptions.paths in packages' tsconfig -- I don't think this is needed considering pnpm will symlink the source code and resolve to the proper entrypoints. there's a few cases where it appears the declared paths are intentionally bypassing the default module resolution behavior
2. use .ts config files where applicable, such as vitest's config -- the codebase is largely written in TypeScript and while porting to ts doesn't provide a material benefit it'll align towards the existing ts-driven codebase
3. consider biome as an alternative to eslint -- this one is a bit selfish in that I prefer the out-of-the-box rules from biome that are somewhat already covered by the existing eslint, however there are also instances where I'm seeing eslint errors
4. extremely selfish, consider standardizing on 2-space indentation to align with common js/ts defaults
5. add a node version file, .node-version to ensure contributors are using the appropriate node version -- the publish action uses node 24, however this can be centralized into a node version file that both contributors and the pipeline can benefit from
6. fix type resolution errors for common packages, since they're exporting raw js files I'm seeing ts errors locally (ex https://github.com/modelcontextprotocol/typescript-sdk/blob/main/common/vitest-config/package.json#L7)
7. this one sounds silly but a package.json sorter like https://www.npmjs.com/package/prettier-plugin-packagejson -- again, not a material benefit to be gained here other than enforcing a stylistic choice to ensure each package.json has key/value pairs declared in the same order, reducing cognitive overhead of hunting for specific keys and potential merge conflicts
8. revise usage of dependencies for shared packages. for example, the tsconfig package should declare a peer dependency for ts instead of a dependency to enforce consumers to use the same package version(s) used to author the tsconfig.json file. consuming packages are already declaring the typescript package version specified in the devTools catalog, so we won't see a difference with this change, however it is appropriate to declare this specific package as a peer https://github.com/modelcontextprotocol/typescript-sdk/blob/main/common/tsconfig/package.json#L6
9. in addition to 8, all packages should be declaring typescript as a devDependency (see https://github.com/modelcontextprotocol/typescript-sdk/blob/main/common/tsconfig/package.json#L6)
10. clean up dependencies declared in the root package.json, move dependencies like eslint-* to the shared eslint config package -- there are quite a few dependencies here that don't appear to be used/needed
11. switch moduleResolution from NodeNext to bundler -- since the packages here are bundled with tsdown (which uses rolldown under the hood), it's a better developer experience to allow the bundler the handle module resolution instead of using node's that requires the use of explicit file extensions on import statements
12. remove types from tsconfig -- this overrides default behavior and I don't see a benefit to including it. if a consuming package brings it's own @types/* packages, you will need to override types in the consumer's tsconfig instead of allowing ts to resolve on its own
13. enforce all formatting and linting checks on PR's to ensure continuous integration of code that aligns with the preferred style guide
14. migrate from using pnpm/setup-action to using corepack directly in all GitHub Action workflows -- this will ensure the workflows align with the local development workflows specified in the contributing guide. This is another one where you won't see a huge benefit up front but it will ensure the actions are using the same workflows as local dev
15. scripts are referencing files that do not exist -- probably slipped through the cracks during the repo refactor for v2

some of these items can arguably be considered "nice to have"

Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.

Additional context
Add any other context or screenshots about the feature request here.

Start by reviewing contributing.md, the package tsconfig files such as common/tsconfig/tsconfig.json, package.json manifests, and the GitHub Actions workflows mentioned in the issue. First separate the 15 proposals and confirm which existing decisions are intentional; done requires an agreed scope and independently verifiable changes for the selected items.