chore(dependencies): update decoders to v2

[daragh-king-genesys]

Upgrade decoders dependency from v1 to v2

Summary

This PR upgrades the decoders library from v1.x to v2.8.0, updating all decoder implementations to use the new v2 API. The migration maintains backward compatibility while adopting the improved API design and stricter validation.

Key Changes

1. API Replacements

• dispatch + guard → taggedUnion + verify: Simplified tagged union validation in ClientToHost.ts and HostToClient.ts
• object → exact: All object decoders now use exact (v2's renamed equivalent of v1's object). This maintains the existing strict validation behavior that rejects unknown properties, ensuring protocol integrity and catching malformed messages early.
• mixed → unknown: Updated type-safe handling of arbitrary data
• hardcoded → optional + transform: Replaced deprecated hardcoded with optional fields and default value transformation
• map → transform: Updated functional transformations to use the new transform method

2. Affected Files

• ClientToHost.ts - Updated message validation
• HostToClient.ts - Updated message validation
• LabeledMsg.ts - Refactored to use exact, optional, and transform for protocol/version defaults
• Lifecycle.ts - Replaced mixed with unknown, object with exact
• ModalRequest.ts - Updated decoder and made modalData optional
• Notification.ts - Simplified toast type conversion using transform
• PageMetadata.ts - Updated to use exact and unknown
• Publication.ts - Made payload optional, updated decoder
• PromptOnLeave.ts - Minor formatting update

3. Type Safety Improvements

• Maintains strict object validation (rejects unknown properties) to catch protocol errors
• Better type inference with unknown instead of mixed
• Cleaner API with verify() method instead of guard() wrapper

Why exact instead of object?

In decoders v2, the old object decoder was renamed to exact. The new object decoder is permissive (allows extra properties). We use exact to preserve the original strict validation behavior, which is appropriate for a messaging protocol where unexpected fields indicate errors or version mismatches.

Migration Reference

Changes follow the official migration guide: https://github.com/nvie/decoders/blob/main/MIGRATING-v2.md

Testing

All existing tests pass with the updated decoders implementation. The changes are API-compatible and maintain the same runtime behavior.

[jordanstith15]

So maybe I'm missing some context, but from what I read in the migration docs and changelog, "either" still exists and "hardcoded" is supposed to be replaced by "always".
Also these fields didn't seem to be optional before. There is even a comment saying to make the fields mandatory in version 4.0.0, which is older than the current version..

[daragh-king-genesys]

Ya I was wrong, either still exists in v2, and hardcoded should be replaced with always. I've updated to use either(constant(...), always(...)) which preserves the original semantics. The fields stay non-optional in the output type, as intended.