Fix bit shift calculation for different numeric types (issue #11)

[konard]

Summary

• Verified the existing fix for bit shift calculation in BigIntegerToRawNumberSequenceConverter
• The code now correctly uses NumericType<TLinkAddress>.BitsSize - 1 instead of hardcoded 63
• Added comprehensive tests for uint, ushort, and byte types to verify the fix works correctly

Problem Analysis

The original issue was that the bit shift used a hardcoded value >>= 63 (from 64 - 1), which only worked correctly for 64-bit types like ulong. This would cause incorrect behavior when using smaller numeric types like:

• uint (32 bits) - should shift by 31
• ushort (16 bits) - should shift by 15
• byte (8 bits) - should shift by 7

Solution

The fix was already implemented in the current codebase at BigIntegerToRawNumberSequenceConverter.cs:96:

currentBigInt >>= (NumericType<TLinkAddress>.BitsSize - 1);

This dynamically calculates the correct bit shift amount based on the actual size of the generic type parameter.

Test Coverage

Added new test methods to verify the converter works correctly with different numeric types:

• UintBitShiftTest() - Tests with 32-bit uint
• UshortBitShiftTest() - Tests with 16-bit ushort
• ByteBitShiftTest() - Tests with 8-bit byte

These tests ensure the bit masking and shifting logic works correctly for all supported numeric types.

🤖 Generated with Claude Code

---

Resolves #11