[bmc08gt]

Bugsnag group 6aba977 ("Request validation failed") holds 1,057 events from eight different fields. Every ValidationException is built from the same CodeServerError.<init> frame, so Bugsnag groups them together, and Throwable.kt dropped the failed rule, leaving nothing but the message to tell them apart. Hashing on the message would split the groups again whenever a contract limit changes (the username {2,15} to {2,30} bump is the example in the triage brief).

This implements Decisions 3 and 4 and the Android item for Throwable.kt:12 in docs/specs/bugsnag-cleanup.md, using the per-field table in the triage brief on docs/bugsnag-validation-triage.

• Violation now carries rule next to field; toValidationOrElse copies it from FieldViolation.
• ValidationException is ConditionallyNotifiable. It is notifiable (so WARNING) when a violation is on addresses, address or user_id, which the request builders fill themselves. group.title, display_name, currency name and username are unchanged and stay at INFO; those need UI guards or the contract bump, not a warning.
• ValidationException.groupingHash is the sorted, de-duplicated set of <field path with [N] removed>:<rule>. BugsnagErrorReporter sets it as the event's grouping hash, whether the exception is the error or its cause. The message is not part of it.

Tests: ThrowableExtensionsTest covers rule and field surviving into the exception, messages[3].content and messages[7].content sharing a hash, a changed limit message not changing the hash, different rules or fields on one request giving different hashes, and the notifiable split between client-filled and user-input fields. BugsnagErrorReporterTest covers the reporter picking the hash from the error or its cause and leaving other errors on default grouping.

Not in this PR: the empty NoId, the short token address caller, the UI input checks and the 0.24.0 contract bump. A WARNING on client-filled fields will also report the next pin drift on those fields, which the triage brief expects.