test: add Xquik OpenAPI 3.1 e2e fixture

[kriptoburak]

Summary

• Add a compact OpenAPI 3.1 fixture based on the public Xquik tweet search operation.
• Cover info, path listing, operation parameters, schema components, and security scheme resources in the e2e spec-loading suite.
• Refresh transitive production lock entries for Hono and qs so the project production audit stays clean.

Validation

• npm ci
• npm run build
• npm run type-check
• npm run lint
• npm run format:check
• npm test
• npm run test:coverage
• production npm audit at high severity
• production license check
• whitespace diff check

[codacy-production]

Up to standards ✅

🟢 Issues 0 issues

Results:
0 new issues

View in Codacy

🟢 Metrics 0 complexity · 0 duplication

Metric	Results
Complexity	0
Duplication	0

View in Codacy

_{NEW Get contextual insights on your PRs based on Codacy's metrics, along with PR and Jira context, without leaving GitHub. Enable AI reviewer
TIP This summary will be updated as you push new changes.}

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[kadykov]

Hi @kriptoburak, thank you for your first contribution and for taking the time to run the full validation suite!

After reviewing the PR, I have a few concerns regarding the addition of these specific fixtures:

1. Test Suite Conciseness: To keep the CI pipeline fast and maintainable, I aim to keep the test suite as lean as possible. I'm not currently seeing a gap in our test coverage that necessitates an additional OpenAPI 3.1 fixture.
2. Generic Fixtures: For our test examples and fixtures, I prefer to use neutral, brandless data (e.g., example.com or foo/bar) rather than real-world commercial services. This ensures the tests remain focused on the logic of the MCP server rather than the specificities of a particular product. This is why we use the community-standard Pet Store API for our integration tests.

If you believe there are specific edge cases or schema patterns in the Xquik API that our current tests do not cover, please let me know! I would be happy to incorporate those missing cases if they are implemented using generic, brandless examples.

Thanks again for your interest in the project!

[kadykov]

Hi @kriptoburak, we've moved the technical improvements from this PR into a brand-neutral implementation in PR #197