Fix #23: tolerate unset (0xFF) stype in v3 SymbolMappingMsg decode

[tbeason]

Summary

Fixes #23 — the generic read_record path crashes on DBN v3 captures with
ArgumentError: invalid value for Enum SType: 255.

_read_symbol_mapping_v2 (src/decode.jl) did an unguarded SType.T(byte) on
the stype_in/stype_out fields of a v2+ SymbolMappingMsg. A DBN v3 live
gateway can emit an unset stype as 0xFF (the documented sentinel), so
decoding real v3 live captures threw on the first control record — typically
after exactly one data record — making v3 captures effectively undecodable
through the generic reader. (v1 files decode fine; this is v3-specific.)

Fix

• Add an explicit SType.UNDEF = 255 member so the enum constructor is total
  on the 0xFF sentinel instead of throwing.
• This keeps the non-nullable SymbolMappingMsg stype fields representable and
  round-trips losslessly through encode (UInt8(SType.UNDEF) == 0xFF), so no
  struct/API change is needed.
• Also fixes the same latent crash on metadata stype_out (decode.jl:239).
  Metadata's nullable stype_in still decodes 0xFF to nothing, unchanged.

Why this slipped through (test-gap analysis)

The gap is structural, not an oversight. Every existing SymbolMappingMsg
test is a construct → encode → decode → compare round-trip built through the
typed Julia constructor with valid enum values. Such a round-trip can never
produce a 0xFF stype byte if the type system can't represent one — the encoder
only writes bytes for valid SType members, so the decoder never sees the
sentinel. The only way to hit SType.T(0xFF) is to decode bytes the encoder
didn't author (a real gateway capture).

Lesson: round-trip tests verify the encoder/decoder agree with each other;
they can't verify the decoder against wire values the encoder is incapable of
emitting. Those need raw-wire decode fixtures.

Tests

• New test/test_issue23_unset_stype.jl:
  • asserts SType.T(0xFF) == SType.UNDEF and UInt8(SType.UNDEF) == 0xFF
    (unit-level guard; this threw pre-fix);
  • decodes a v3 (MIX schema) file with a SymbolMappingMsg whose stypes are
    unset, interleaved with a TradeMsg, via the generic read_record loop —
    the exact path from the issue's reproduction.
• Full suite green locally: 3558/3558 passed.

Relationship to PR #22

Independent. PR #22 reworks the v3 InstrumentDefMsg layout; this touches the
SymbolMappingMsg decode and the SType enum, in regions far from #22's edits,
so the two merge cleanly in either order.

🤖 Generated with Claude Code