v1.8.2 - TESTING ONLY - Step 6d progress and hard deadlines

v1.8.2 — Step 6d progress and hard deadlines (TESTING ONLY)

TESTING ONLY - persistence collection progress and hard deadlines.

• Fixed the silent unbounded wait at guided Step 6d: read-only inventory now
  runs in an isolated worker with a 60-second per-section deadline and a
  300-second overall deadline. The exact provider that stalled the owner's
  prior run is not established; new section/heartbeat output identifies it.
• Added live section progress, periodic still-collecting messages and a local
  persistence/collection-progress.log. A stalled worker is terminated;
  persistence collection stops as Incomplete, removal is disabled, and the
  normal report path can continue with a nonzero outcome and the last section.
• Approval/removal remains in the visible attended parent, never the worker.
  Deadlines do not approve cleanup, suppress gaps or create a clean verdict.
• Added harmless blocked-provider, total-budget, success and worker-failure
  fixtures; no live Windows collection, scanner or removal was run by agents.
• Includes the v1.8.1 battery-check console visibility fix unchanged.

Owner-reported symptom and root cause

The run sat forever at STEP 6d/9: Persistence inventory and review. The old
code collected synchronously with no output and no time bound, so a stalled
Windows provider produced a silent, indefinite wait. The exact provider that
stalled your machine is still not established — the new section output and
persistence/collection-progress.log are there to name it on your next run.

What this build changes

Before	After
Silent, unbounded wait	Live [Persistence] Collecting <section> ... plus still-collecting heartbeats
No time limit	60s per section, 300s total; the stalled worker is terminated
Nothing to inspect afterwards	persistence/collection-progress.log (capped at 1 MB, truncation marked)
Ambiguous state after a hang	Collection is Incomplete, persistence removal disabled, report still produced with a nonzero outcome

Approval is unchanged: the visible attended console still owns removal review,
and no deadline can approve cleanup or turn incomplete evidence into a clean
verdict. This aborts the remaining collection rather than claiming those sources
were inspected.

Verification

• Exact source: 6eaed827b0d2d659d026f380fc76987a3e580931
• Windows CI (Server 2022 + 2025, PowerShell 5.1 + 7, including the extracted ZIP):
  https://github.com/pupontech/screenconnect-cleanup/actions/runs/37776056082 — green on Windows Server 2022 and 2025 under PowerShell 5.1 and 7, including the same fixtures run from the extracted ZIP.
• Harmless fixtures prove: a stalled provider times out; progress is observed
  while the run executes; the worker is terminated and not orphaned; a
  provider error propagates the real worker exit code; the total budget cannot be
  bypassed by repeated progress markers; a missing worker still fails closed; a
  leftover progress log is refused with the fresh-run requirement.
• Independent review by two GLM-5.3 lanes: PASS on bounded-collection
  correctness and on test/packaging validity. Their findings were fixed before
  this build (unresolvable-worker exit code, log-cap marker, fresh-run refusal,
  fixture timing margin, PID-identity-checked cleanup, live streaming proof).
• Full local matrix: 33/33.
• A real Windows sharing defect that CI caught is fixed: the progress log is opened FileShare.ReadWrite so it can be tailed while the run writes, and the fixture now reads it during the run — which is exactly why the local suite could not see it.
• ZIP: 46 members, exact per-member hash manifest, version and full source SHA verified; this download preserves the tested Windows 2022 artifact bytes.
• SHA-256: 4f1ed3ad93659ecfeb0bd00e469f7739beed91ddc92a88ebe8295d3306504e6b

Before you retry

Verify the checksum and extract this NEW ZIP into a fresh folder — a reused run
directory is refused by design. The agents ran no live scanner, installer or
removal; your live acceptance of collection coverage, approval UX and rollback
restoration is still required.

If Step 6d ever appears stuck again, it will now name the section and stop on its
own; send me the last [Persistence] lines and collection-progress.log.