fix(cesr): strip identifier bits before reconstructing long-form count in decode_count

[ManthanNimodiya]

Summary

decode_count has a bug in its long-form path (counts ≥ 4096). After matching
the 6-byte header, it reconstructs the count as index << 24 | next — but
index is the raw lower-12-bits of the header word, which encodes
(identifier << 6) | count_high_6. The identifier bits are never stripped, so
the reconstructed count is wrong for any non-zero identifier. In debug builds
this panics (u32 overflow); in release builds it silently returns a garbage value.
Any TSP message whose encoded payload or envelope exceeds ~12 KB triggers the
long-form path and will fail to decode correctly.

Root Cause

tsp_sdk/src/cesr/decode.rs, function decode_count, long-form branch:

// Before — index still carries identifier bits in bits[11:6]
Some(index << 24 | next)
// After — mask to count_high_6 only
Some((index & 0x3F) << 24 | next)

The encoder (encode_count) correctly packs count >> 24 into the low 6 bits
of the header word. The decoder needs to extract exactly those 6 bits before
shifting, not the full 12-bit index.

Changes

• tsp_sdk/src/cesr/decode.rs — one-character fix: index << 24 →
  (index & 0x3F) << 24
• tsp_sdk/src/cesr/mod.rs — added decode_count_long_form_round_trips
  test covering all four TSP framing identifiers (ETS_WRAPPER, HOP_LIST,
  S_WRAPPER, PAYLOAD) at the exact long-form boundary (4096) and at larger
  values, verifying encode→decode round-trips correctly and the stream is
  fully consumed

Testing

cargo test -p tsp_sdk

New test: decode_count_long_form_round_trips — 8 cases covering all real
TSP framing identifiers in both boundary and large-count scenarios.

Checklist

• Bug reproduced and root cause confirmed
• Fix is a single targeted change
• Round-trip tests added for every affected identifier
• DCO signed
• Follows existing code style

[tediou5]

Wait a moment, let me check the definition of this part in the spec first.