maven-artifact:3.9.6 (used only for ComparableVersion) transitively pulls
plexus-utils:3.5.1, which is affected by CVE-2025-67030 — a directory
traversal / Zip Slip in org.codehaus.plexus.util.Expand.extractFile
(CVSS 8.8). The vulnerable code is not reachable from this client, but the
jar is flagged by SCA scanners.

Add a dependencyManagement pin forcing the patched plexus-utils 3.6.1.
Staying on the 3.x line avoids the plexus-xml package split introduced in
4.x. dependency:tree confirms plexus-utils now resolves to 3.6.1 and the
build/tests are unaffected.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

…plexus-utils

fix(deps): pin plexus-utils to 3.6.1 to resolve CVE-2025-67030

Release the CVE-2025-67030 plexus-utils fix as a patch. Bumps the Maven
artifact version and the hardcoded clientVersion used in the User-Agent
header to keep them in sync.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

The examples module was left at 6.2.5 (missed in the 6.3.0 release). Bring
its own version and its messagebird-api dependency in line with the 6.3.1
release, matching the convention in messagebird#275.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

chore(release): bump version to 6.3.1

Meta's parent business-scoped user ID rollout adds two identifiers our
webhooks now forward, neither of which the SDK could express.

- ConversationSenderMetadata gains parentUserId, the sender's parent
  BSUID (from Meta's messages[].from_parent_user_id).
- ConversationRecipientMetadata is new, modelling
  status.metadata.recipient.{userId,parentUserId}. Status payloads did
  not carry the recipient's own identity before — messageMetadata.to is
  only an echo of the address the customer addressed — so this is the
  first way to learn a contact's BSUID from a status webhook.
- ConversationStatusMetadata is new, modelling the enclosing
  status.metadata block. pricing and conversation stay raw maps: they
  are near-verbatim passthroughs of Meta's objects and keep their
  snake_case keys, while recipient is ours and is camelCase. Unmodelled
  keys (e.g. biz_opaque_callback_data) are collected rather than dropped.

Both new types parse under a plain ObjectMapper, so consumers need not
disable FAIL_ON_UNKNOWN_PROPERTIES. recipient is absent from payloads
for accounts that receive no BSUIDs, and deserialises to null there.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

The payload types added in 6.3.0 are meant to be deserialized by
consumers in their own HTTP handlers, but only parsed under a mapper
with FAIL_ON_UNKNOWN_PROPERTIES disabled — which the SDK's internal
mapper does and a plain ObjectMapper does not. A consumer following the
javadoc got an UnrecognizedPropertyException, and would get one again
every time the platform adds a field to a payload they already parse.

Adds @JsonIgnoreProperties(ignoreUnknown = true) to the four types on
the status payload path: ConversationStatusMessageMetadata,
ConversationMessageMetadata, ConversationSenderMetadata and
ConversationContent. This matches the new types added alongside it and
makes the webhook-parsing story uniform.

Deserialization only loosens, so nothing that parsed before stops
parsing; serialization is untouched, which the existing send-request
tests cover. The 6.3.0 test no longer needs to disable the feature by
hand, and a new test parses a payload carrying unknown keys at every
nesting level under a plain mapper.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

…ipient-parent-user-id

feat: support recipient BSUIDs on WhatsApp status webhooks (6.4.0)