Cut Post-PPKG settle from 180s to 60s

Empirical evidence: MDM baseline policy push lands well within 60s
after PPKG triggers immediate reboot path on bays where assignment
filter matches. Bays where it doesn't deliver in 60s aren't going
to deliver in 180s either - they're blocked on an assignment-filter
or dynamic-group lag (sometimes 30+ min in GCC-High), not on the
raw sync window. Trimming 120s of dead wait off every imaging cycle.

Aggressive 30s Schedule #3 hammer + early-exit on baseline (>=5
subkeys) preserved - those still help bays that DO deliver fast.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

playbook/shopfloor-setup/Run-ShopfloorSetup.ps1

@@ -471,7 +471,7 @@ if (Test-Path -LiteralPath $enrollScript) {
     Write-Host "=== Running enrollment (PPKG install) ==="
     Write-Host "NOTE: PPKG schedules a near-immediate reboot. We will cancel"
     Write-Host "      it and hand off to Monitor-IntuneProgress -PostPpkg, which"
-    Write-Host "      runs a 180s settle (giving MDM time to push baseline"
+    Write-Host "      runs a 60s settle (giving MDM time to push baseline"
     Write-Host "      policy) and then performs a clean reboot."
     try { Stop-Transcript | Out-Null } catch {}
     & $enrollScript

playbook/shopfloor-setup/Shopfloor/lib/Monitor-IntuneProgress.ps1

@@ -80,11 +80,11 @@ param(
     # The persistent @logon sync_intune task takes over after reboot.
     [switch]$PostPpkg,
     # -PostPpkgSettleSec: how long to wait before the clean reboot when
-    # in -PostPpkg mode. 180s empirically gives MDM enough time to push
+    # in -PostPpkg mode. 60s empirically gives MDM enough time to push
     # the baseline policy (4 -> ~30 PolicyManager subkeys) so when techs
     # see sync_intune resume after reboot, the readiness signals are
     # already meaningful instead of "policy still pulling".
-    [int]$PostPpkgSettleSec = 180
+    [int]$PostPpkgSettleSec = 60
 )
 
 # ============================================================================