feat: render byte sequence call args as text or hex instead of per-byte cards

[stepanLav]

Purpose

With the metadata-proof parsing flow (payload types 06/07), Vec<u8> call arguments are rendered as one numeric card per byte. A system.remarkWithEvent remark turns into a screen-long column of decimal numbers (123, 34, 107, …) that is impossible to review before signing.

The legacy decoder (decoding_sci.rs) already special-cases remark/remark_with_event fields and shows them as a single text card — this behavior was lost when call decoding moved to the state-machine parser.

Scope

• rust/parser/src/state_machine.rs — byte sequences (Vec<u8>) now collapse into a single card in visit_sequence: UTF-8 text when the current state expects text, 0x… hex otherwise (also a fallback for non-UTF-8 "text" bytes). Added a minimal U8Collector visitor to drain the bytes without producing per-byte cards.
• rust/parser/src/state.rs — new TextState and a State::expects_text() hook; the default process_field enters TextState for fields named remark/remark_with_event, mirroring the legacy decoder rule.
• rust/parser/src/tests.rs — three new tests: remark rendered as text, invalid-UTF-8 remark rendered as hex, non-remark byte sequence (e.g. system.set_code) rendered as a single hex card.

No UI changes needed: ParserCard::Text already maps to TextCard and is rendered by both apps.

Discussion

• Hex (not per-byte) was chosen as the generic Vec<u8> rendering: a single 0xdeadbeef line is reviewable and matches how other tools display byte blobs. Text rendering is deliberately limited to remark-like fields to avoid content-sniffing on a signing device.
• The legacy decoding path is untouched, so old QR payload types behave exactly as before.

Screenshots

Before: system.remarkWithEvent remark shown as a column of decimal byte values, one row per byte.

Screenshot

After:

Screenshot