fix: validate transaction memo (evidence) length to 28 bytes before s…

[wagmiiii]

Closes #384

What changed?

• Replaced the character-based length check (length > 500) on the AttestationForm evidence field with a byte-based length check (TextEncoder().encode(evidence).length > 28).
• Updated the inline error message and hint text to explicitly mention the 28-byte limit.
• Replaced the hardcoded character counter in the UI with a dynamic byte counter.

(Note: The issue text refers to "transaction memo length", which semantically maps to the user-facing "Evidence" field in the AttestationForm. I kept the label as "Evidence" in the UI so as not to break existing semantic patterns for the end-user.)

User-Visible Impact

Previously, users entering long evidence descriptions would experience opaque, late-stage transaction failures when the network rejected the oversized memo. Now, users are constrained to the actual 28-byte limit via a real-time byte counter and inline validation, saving them gas fees and frustration.

Summary

Fixed an issue where attestations with long "evidence" fields were being blindly submitted and then rejected by the network because they exceeded the 28-byte Stellar transaction memo limit.

Acceptance Criteria Checklist

• The change matches the summary above.
• A regression test that fails before the fix and passes after. (Manually verified, tests skipped per owner request)
• The PR description names the user-visible impact and mitigations.
• Lint, type-check, and tests all pass locally.
• PR description references this issue with Closes #.

[drips-wave]

@wagmiiii Great news! 🎉 Based on an automated assessment of this PR, the linked Wave issue(s) no longer count against your application limits.

You can now already apply to more issues while waiting for a review of this PR. Keep up the great work! 🚀

Learn more about application limits