feat: parse Q10 archived map packets

[hCoureau]

Summary

• classify Q10 01/02/03/04 archive packet markers with a typed integer enum
• parse saved-map and clean-record detail packet layouts, including bounded historical paths
• route archive packets through the protocol and allow the map renderer to consume historical paths

Important

This is a stacked pull request based on #933. The isolated change for review is commit 95d268e. After #933 merges, this branch will be rebased onto main before merge so the final diff and history contain only this change.

Design against the #933 review priorities

• End-user API: no trait or end-user API changes are introduced in this slice.
• Trait lifecycle: no trait state is introduced; archive consumption is deliberately deferred to feat: expose Q10 map archives #937.
• Parser boundary: the protocol exposes one discriminated Q10MapPacket model for current and archived maps, so consumers do not inspect raw packet markers.
• Parser internals: parsing is selected by the required typed packet kind and all archive-specific reads are bounded and covered by malformed/truncated-packet tests.

Review notes

This split incorporates the earlier review direction on #933: packet kinds own their wire integer values, the packet kind is required and parsed first, and unused trailing packet bytes are not exposed as public state.

No private map captures or account data are included.

Validation

• 981 passed, including 92 snapshot tests
• all pre-commit hooks passed
• package build passed

Related work

• Depends on fix: request Q10 maps without starting cleaning #933
• Tracks the read-only map work in Add Missing Q10 Feature support #767

AI assistance disclosure

This contribution was prepared with OpenAI Codex assistance. I reviewed the submitted changes and test results and take responsibility for the contribution.

[allenporter]

when this kind of map packet is received, how many of these other fields are also included?

What i'm wondering is if a historical trace kind has a lot of overlap with other fields in Q10MapPacket or if it needs to be a separate type. basically as more fields are added the map packet seems like a sparse object. You could imagine each kind Q10MapPacketKind has a separate dataclass for example, if the overlap is low.