Part marker: a misconfigured bay is now loud, and the listing loop is bounded

Every failure of Get-TelesisPortConfig was filed as "no Telesis marker
configured on this PC" and exited 0. That is correct for the many PCs which are
not marker bays, and wrong for a bay whose registry key EXISTS and could not be
read: a half-configured marker was silently never backed up again, which is
exactly the failure shape this feature was built to prevent. The absent-key case
now throws a distinguishable exception and stays quiet; anything else is logged
every cycle and counted as a skip.

Get-TelesisFileList was unbounded. The receiver drives that loop, so a
controller repeating a name or answering noise on a marginal cable would spin
for ever - and not harmlessly, because it holds the MARKING port while
GE-Enforce waits on the script with no timeout, so one chatty controller wedges
the enforcement cycle and the operator cannot mark a part. Now capped by count,
by elapsed time, and by repeat detection, all of which THROW: a partial listing
presented as a complete snapshot would be worse than failing.

Baud and Data Bits parse with TryParse. Note the narrower reason than it looks:
[int]'' is 0 in PowerShell, so empty and non-numeric values were already handled
by the zero-check. What was not handled is a numeric string too large for Int32,
which throws on the cast and would have been filed as "not a marker bay".

Verified in the win11 VM as SYSTEM, against both the old and new module: absent
key stays quiet, a key without Port Id is loud, garbage and out-of-range baud
both fall back to 9600, a real 19200 is still honoured, a repeating controller
stops at once and endless unique names stop at the cap.

playbook/shopfloor-setup/common/scripts/Backup-PartMarker.ps1

@@ -328,11 +328,23 @@ if ($busy) {
 
 try {
     $portconfig = Get-TelesisPortConfig
-} catch {
-    # Every PC type that is not a part-marker bay lands here, permanently.
+} catch [System.Management.Automation.ItemNotFoundException] {
+    # The registry key is absent: this PC is not a part-marker bay. Quiet and
+    # permanent, which is correct - most of the fleet lands here every cycle.
     Write-ShopdbQuietState -Kind $KIND -State 'no-marker-config' -Message (
         "No Telesis marker configured on this PC ($_). Nothing to do.")
     exit 0
+} catch {
+    # The key EXISTS and reading it failed: a marker bay that is misconfigured,
+    # or a registry permission problem. Filing this as "not a marker bay" - as
+    # this used to - meant a half-configured bay was never backed up again and
+    # nothing anywhere said so. It is the silent-failure shape this whole
+    # feature exists to avoid, so it is logged every cycle and counted as a
+    # skip, not swallowed.
+    $message = "Marker configuration present but unreadable: $_"
+    Write-ShopdbBackupLog -Kind $KIND -Message $message
+    Add-ShopdbBackupSkip -Kind $KIND -Reason 'marker-config-unreadable'
+    exit 1
 }
 
 # -MachineNumberFallback, not a shared default: a marker bay legitimately has