fix: use optional instead of exactOptional in KeyringCapabilitiesStruct

[hmalik88]

Change KeyringCapabilitiesStruct to use optional instead of exactOptional for nested fields

exactOptional rejects explicit undefined values while optional accepts them. The distinction is meaningless for this struct because capabilities data is always JSON-sourced (from Snap manifests and JSON-RPC messages), and undefined cannot exist in JSON. JSON.parse never produces it, and JSON.stringify silently drops keys with undefined values.

The practical motivation: @metamask/snaps-utils mirrors this struct for manifest validation, where PermissionsStruct is annotated as Describe<InitialPermissions>. Superstruct's Describe<T> maps TypeScript's prop?: T to a struct whose refiner accepts T | undefined, but exactOptional(T) produces a refiner that only accepts T. These are incompatible at the type level, forcing consumers to maintain a duplicate struct with optional just to satisfy Describe. Switching the canonical struct to optional eliminates this duplication with no change in runtime behavior for JSON data.

---

Note

Low Risk
Low risk: schema validation is loosened only to accept explicit undefined for nested capability fields; behavior for JSON-derived data should be unchanged.

Overview
Updates KeyringCapabilitiesStruct to use superstruct optional() (instead of exactOptional()) for nested capability objects and their fields (bip44, privateKey, custom).

Adds a changelog entry documenting this as a fix, primarily improving TypeScript Describe<> compatibility while keeping effective JSON validation the same.

^{Written by Cursor Bugbot for commit ba24cd8. This will update automatically on new commits. Configure here.}