Fix ToBytes corrupting entries lacking the 32-bit kvno extension (#2)

[p0dalirius]

Linked Issue

Closes #2

Root Cause

The 32-bit key version number is an optional trailing extension to a keytab entry, present only when at least 4 bytes remain in the record. FromBytes read it conditionally but did not record whether it had been present, so ToBytes had no way to tell entries that carried the extension from those that did not — and it appended the 32-bit vno unconditionally. Every serialized entry therefore gained 4 trailing bytes and an inflated size field, corrupting any keytab that was loaded and written back.

Fix Description

Add a HasVno field to KeytabEntry that FromBytes sets when the 32-bit kvno extension is present. ToBytes now emits the 32-bit vno only when HasVno is true. Entries parsed without the extension serialize back to byte-identical output; entries parsed with it preserve it. Newly constructed entries default to HasVno = false, matching modern keytabs that omit the extension.

How Verified

• go test ./... passes, including new tests.
• Loading example.kt and re-serializing now produces an identical 204-byte buffer; entry size fields stay 0x0000003a, where before the round-trip produced 216 bytes with size 0x0000003e.

Test Coverage

• Added: src/keytab/KeytabEntry_kvno_test.go:
  • Test_KeytabEntry_NoKvnoRoundTrip — an entry without the extension serializes to identical bytes and HasVno is false.
  • Test_KeytabEntry_KvnoRoundTrip — an entry with the extension preserves the 32-bit vno and HasVno is true.

Scope of Change

• Files changed: src/keytab/KeytabEntry.go, src/keytab/KeytabEntry_kvno_test.go
• Submodule pointer updated: no
• Behavioral changes outside the bug fix: none

Risk and Rollout

Output-only change to entry serialization; existing involution tests still pass. Safe to merge directly.