Refactor archive tar construction into dedicated builder

[woutervanranst]

Summary

Move tar bundle construction concerns out of ArchiveCommandHandler into a dedicated TarBundleBuilder-style type.

Motivation

The archive pipeline currently interleaves pipeline orchestration with tar-specific mechanics:

• TarWriter and MemoryStream lifecycle
• tar entry naming by content hash
• tar entry metadata accumulation
• tar target-size thresholding
• sealing tar bytes and computing the tar chunk hash

Separating these responsibilities would make the archive handler easier to read and keep tar-specific behavior isolated and testable.

Proposed Shape

Introduce a focused builder/payload pair in the archive command feature area:

• TarBundleBuilder: owns tar accumulation, entry writing, size thresholding, sealing, and hash computation.
• TarBundlePayload: carries sealed tar bytes, tar hash, uncompressed size, and member metadata.

ArchiveCommandHandler would remain responsible for archive workflow orchestration:

• routing small files to the tar builder
• publishing lifecycle/progress events
• uploading sealed tar chunks
• creating thin chunks
• updating the chunk index
• writing filetree entries
• pointer/delete bookkeeping

Notes

Keep mediator/event publishing in ArchiveCommandHandler unless there is a strong reason to make the builder depend on pipeline notifications. The builder should stay focused on tar construction, not archive side effects.

Acceptance Criteria

• Archive tar construction state is no longer managed directly inside ArchiveCommandHandler.
• Existing small-file tar archive behavior is preserved.
• Tar bundle sealing remains in-memory and produces a seekable upload source.
• Targeted tests cover tar builder sealing and final partial-bundle behavior.