Harden deserializeParams against nested stringified params

[ksinder]

Description

MCP clients sometimes double-serialize nested object/array parameters, sending them as JSON strings. deserializeParams already handled top-level stringified params and shallowly parsed array items, but it used asymmetric recursion: it descended into object properties yet only string-parsed array items one level deep. A stringified object that was a property of an array element (e.g. { children: [{ paragraph: '{"rich_text":[...]}' }] }) was forwarded to the Notion API as a raw string.

This replaces it with a single uniform recursive walk (deserializeValue) that visits every object property and array element, decodes JSON-looking strings, and recurses into the result. A bounded unwrapJsonString helper also resolves values that were JSON-encoded more than once (e.g. JSON.stringify(JSON.stringify(parent))). A string is only transformed when it ultimately decodes to an object or array; strings that decode to scalars (numbers/booleans/null) or to other plain strings are returned unchanged, so genuine string values are never coerced or unwrapped. This is behavior-compatible for everything the previous code handled.

Motivating case: a stringified parent on create-a-comment makes the Notion API throw on "block_id" in <string> and return a 500; normalizing it client-side avoids that. (A complementary server-side guard is being added in notion-next.)

Also bumps the package version to v2.4.1 so the change publishes on merge via the Publish workflow (OIDC trusted publishing).

How was this change tested?

• Automated test (unit, integration, etc.)
• Manual test (provide reproducible testing steps below)

Added tests for create-a-comment parent as a JSON string, a stringified object nested inside an array element object, a double-stringified parent, and scalar/quoted-scalar params being preserved. Full suite (109 tests) and tsc build pass.

Screenshots

N/A