Harden dependency baseline: upgrade axios/ws and enforce patched versions via pnpm overrides - #4

Please address the comments from this code review:

## Overall Comments
- The change from local .eslintrc.cjs files to a centralized .oxlintrc.json may drop app-specific lint rules or ignores; consider validating whether any app relied on custom overrides and, if so, recreating them via per-package config or root-level patterns.
- The new `peerDependencyRules.allowedVersions` block in package.json currently whitelists `*` for several packages; you may want to narrow these ranges to the versions actually in use to preserve the goal of a stricter, security-focused dependency baseline.
- In `testStatelessMcpApp` the double cast `as unknown as ExecutionContext` suggests a mismatch between the test fixture and the real type; consider adjusting the helper’s shape or using a dedicated test interface to avoid broad `unknown` casting and keep type-safety tighter.

## Individual Comments

### Comment 1
<location path="packages/mcp-common/src/test/stateless-app.ts" line_range="50" />
<code_context>
 			waitUntil() {},
 			passThroughOnException() {},
-		}) as ExecutionContext
+		}) as unknown as ExecutionContext

 	describe(`${name} stateless MCP transport`, () => {
</code_context>
<issue_to_address>
**suggestion:** Clarify/justify the double cast to `unknown as ExecutionContext` in the test helper

This change implies the mock object no longer satisfies `ExecutionContext`’s type. Since this helper is shared across stateless MCP transport tests, consider either updating the mock to be structurally compatible with `ExecutionContext` (avoiding the double cast), or add a short comment explaining why the double cast is required. That will help prevent future “cleanup” of the cast that accidentally changes the intended test context.

Suggested implementation:

```typescript
			...(withAuth && { props: TEST_PROPS }),
			waitUntil() {},
			passThroughOnException() {},
			// NOTE: This helper intentionally uses `unknown as ExecutionContext` because the
			//       minimal mock object used in tests does not (and should not) fully satisfy
			//       the `ExecutionContext` interface at compile time. The cast allows tests to
			//       exercise stateless MCP transport behavior without forcing unnecessary
			//       implementation details into the mock. Be careful when “cleaning up” this
			//       cast: changing it to a direct `as ExecutionContext` or altering the mock
			//       shape may accidentally change the intended test context.
		}) as unknown as ExecutionContext

```

If the `ExecutionContext` type evolves or if you decide to align the mock structurally with `ExecutionContext`, you can:
1. Expand the mock object here to implement the required `ExecutionContext` properties/methods and then remove the `unknown` intermediate cast (i.e., use `as ExecutionContext` directly).
2. Update the comment accordingly to reflect that the mock is now structurally compatible and no longer needs the double cast.
</issue_to_address>