Archive progress bar renders empty for thin/pointer-only archives

[woutervanranst]

Context

Follow-up to ff536194 (fix(web): show scanned file count in archive progress), which addressed the confusing "Scanned 0 B" caption for thin/pointer-only archives by also surfacing the scanned file count. That commit deliberately scoped itself to the captions; this issue tracks the related items left out of scope.

Root cause (shared with the caption fix)

For a thin / pointer-only archive (folder holds .pointer.arius stubs, binaries removed after a prior archive), scanned files have no local binary bytes to read:

• ArchiveCommandHandler.cs:316 — fileSize = pair.Binary is null ? 0L : fs.GetFileSize(...) → FileScannedEvent reports 0.
• Consequently ScanCompleteEvent.TotalBytes (and thus JobSnapshot.TotalBytes) is also 0.
• Meanwhile dedup pulls each file's full original size from the chunk index (ArchiveCommandHandler.cs:482), so DedupedBytes climbs.

Problem 1 — layered progress bar reads empty (web)

archiveBarLayers() (Arius.Web/src/app/shared/job-format.ts) divides every layer by totalBytes. For a thin archive totalBytes == 0, so all four layers are 0% and the bar stays empty for the whole run even though work is completing (files deduplicating). The Scan/Hash stage "done" checks (job-detail.component.ts) also gate on totalBytes > 0, so they never flip to done.

Possible directions:

• When the byte-total is 0 but files are being processed, drive the bar (and stage completion) off a file-count denominator instead of bytes.
• Or credit pointer-only files' original size (known at dedup) back into a logical total so the byte model is non-zero — bigger change, also makes Scanned/Total reflect logical dataset size.

Problem 2 — CLI shows the same 0-scanned behavior

The CLI (Arius.Cli/ProgressState.cs, Arius.Cli/Commands/Archive/ArchiveProgressHandlers.cs) consumes the same archive events and will show the same 0-scanned / 0-total behavior for pointer-only inputs. Whatever approach is chosen for the web should be mirrored (or the shared semantics fixed at the event level).

Note

There is also an unrelated pre-existing build break on this branch (Microsoft.OpenApi 3.8.0 vs Microsoft.AspNetCore.OpenApi 10.0.9, CS0200) — tracked/handled separately, not part of this issue.