Add Sequential Thinking tests and update TypeScript SDK versions

[olaservo]

Description

Adds support for automated tests for Sequential Thinking and updates SDK versions.

Server Details

• Server: sequential thinking, everything, filesystem
• Changes to: tests, sdk version

Motivation and Context

There were no automated tests for Sequential Thinking yet, and SDK versions were behind.

How Has This Been Tested?

Only automated tests so far.

Breaking Changes

None

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Documentation update

Checklist

• I have read the MCP Protocol Documentation
• My changes follows MCP security best practices
• I have updated the server's README accordingly
• I have tested this with an LLM client
• My code follows the repository's style guidelines
• New and existing tests pass locally
• I have added appropriate error handling
• I have documented all environment variables and configuration options

[domdomegg]

I think elsewhere we're migrating jest -> vitest. I think vitest works a lot better with TypeScript and is largely a drop-in replacement - possibly we should use that here instead?

(I've also used it in a bunch of other projects and really liked it)

[cliffhall]

I like vitest vs jest as well. The PR in the Typescript repo shows how easy it is to migrate.

[olaservo]

Sounds good. Since I just used the same test framework as other servers here and they also need to be converted, I'll just merge this PR as-is and convert all tests in one go separately: #2882

(This PR was a prerequisite to a couple other followup PRs already, so I'd prefer to have it merged sooner rather than later and unblock those, too.)

[olaservo]

Made the changes here: #2884

[KKonstantinov]

I think elsewhere we're migrating jest -> vitest. I think vitest works a lot better with TypeScript and is largely a drop-in replacement - possibly we should use that here instead?

(I've also used it in a bunch of other projects and really liked it)

Fully support this!