test(corekit): the corekit plain-unittest ordering leg fails on main, and CI never runs it #2115

Two related findings.

1. CI never runs tests/corekit under plain unittest. The unittest-ordering matrix in unit-tests.yml lists cli, const, dumpkit, foundation, interface, project, protocols/internet, toolkit, utilities, vendor and protocols (rest). It has no corekit leg and no integration leg. The integration one may be deliberate; if so it should be documented.
2. That leg fails on main. python util/run_unittest_leg.py corekit at aeb4aadd3 gives 903 tests with 34 failures and 31 errors. fix(corekit): let Windows reopen SeekableReader's buffer file (#2098) #2105's head, merged into main, gives the identical failure set.
   • Where: all of them are in test_enum_lookup_reparent_930_unit (15+), test_enum_lookup_reparent_877_unit (10) and test_enum_get_exception_provenance_923_unit (7+).
   • Symptoms:
     • Tuples differ: (<class 'pcapkit.corekit.enum.EnumLookup'>, <aenum 'IntEnum'>) != (<class 'pcapkit.corekit.enum.EnumLookup'>, <aenum 'IntEnum'>). The reprs are identical, so the class objects differ.
     • EnumLookup not found in (<flag 'Flags'>, …).
     • EnumKeyError where the test expects EnumValueError.
   • Inferred, not proven: an earlier module in the same process re-imports or reloads pcapkit.corekit.enum, or a const module. The later tests then compare against a stale EnumLookup. pytest's per-worker processes would hide this.

Proposed:

• find the polluting module and make it restore sys.modules, or make the comparisons identity-safe if that is the intent;
• add corekit to the ordering matrix (and integration, or document why not), with a test that pins the matrix covers every tests/ subdirectory.