fix: coerce text parameters, and correct copy that misstated server behaviour

[rmyndharis]

A pre-release pass over everything added since v0.9.3, driven by source-level tracing rather than diff reading. Three classes of problem came out of it.

Any expression-driven parameter could crash the node

Thirty-five places read a text parameter as (x as string).trim(). An expression resolving to a number, a boolean or null made that a TypeError, which the executor then wrapped as a server API error naming no field — so the user went looking at their gateway for a problem that was in their expression.

All thirty-five now go through one shared coercion. It is identical for a string; for anything else it stringifies, so a numeric chat ID or session ID simply works, and the existing emptiness and length checks still give a pointed message where the value really is unusable.

contact/checkExists  phoneNumber: 628123456789   -> /contacts/check/628123456789
session/getStatus    sessionId:   12345          -> /api/sessions/12345
message/sendText     chatId:      628123456789   -> {"chatId":"628123456789",...}

Two requests the server would have refused

• Webhook Update forwarded headers: null. The column is NOT NULL and rejects it, surfacing as an opaque 500. The clearing gesture the sibling Filters field documents now sends the empty object the column actually takes.
• Template Update could send an empty patch and report success. It assigned the helper's "not supplied" result straight into the body, so the key stayed present, the all-empty guard never fired, and an update whose only field resolved to null went out as {} — a 200 that changed nothing. That is the exact outcome the helper exists to prevent.

Copy that was factually wrong

Each was checked against the server source or the capability matrix, not assumed:

Said	Actually
Contact Save is "stored on the gateway only"	It writes the WhatsApp account's addressbook and syncs to linked devices. Only the phone's native contacts are untouched.
Unsubscribe "can be reversed by subscribing again"	Subscribe is Baileys only, so on whatsapp-web.js it is one-way. This sat next to a destructive operation.
Pin Chat: "check the returned success flag"	True on whatsapp-web.js. On Baileys the flag is hard-coded true, so a fourth pin reports success and does not stick.
Filters: "use a second Trigger"	The delivery path is derived from the session, so two Triggers on one session collide on the same URL.
Automation Rule: a blank Conditions "matches every message"	An update sends only what you fill in, so a blank leaves the stored conditions alone.
Media conversion notice	Described only the voice output while also shown on Convert to Video.
Status Recipients: "every contact"	That account's usual status audience.
README: one mentions floor	Reply, Edit and Send Template need ≥ 0.23.0; the sends have accepted it since 0.7.14. The README also still claimed the node "does not surface" four operations it now ships.

Also

Automation-rule conditions use the shared JSON reader, so the two filter-shaped fields no longer disagree on whitespace. stableStringify answers for a BigInt instead of throwing, which it had documented as a guarantee, and is now cycle-safe and consistent with a JSON round trip.

Verification

431 tests (up from 426), lint, build, dist-freshness and the Creator Portal scanner all pass. Beyond the suite, these ran clean:

• every request body validated against its server DTO: no undeclared fields, no missing required fields, no wrong types or enums
• every loadOptionsMethod, displayOptions target and options default resolves; no duplicate properties
• the README operations table matches the code exactly, 157/157
• no operation reads a parameter the UI hides
• no secrets, internal hostnames or non-synthetic data anywhere in the range