Drop DynamoDB SystemErrors alarm (never fires at TableName dimension)

AWS/DynamoDB SystemErrors does not emit at the TableName-only dimension,
so payments-dashboard-table-system-errors could never fire. Remove the
alarm resource and its README entry; keep Read/WriteThrottleEvents.

README.md

@@ -101,7 +101,7 @@ All CloudWatch alarms publish to the shared `site-alerts` SNS topic (`arn:aws:sn
 
 Duration thresholds (ms): processPaymentCsv 96000, processPayrollEmail 48000, fetchBoaTransactions 48000, slackAppHome 24000, expenseProcessor 12000, expenseReceiver 4000.
 
-**DynamoDB** (`PaymentsDashboard` table, `TableName` dimension, Sum > 0): `payments-dashboard-table-read-throttle` (`ReadThrottleEvents`), `payments-dashboard-table-write-throttle` (`WriteThrottleEvents`), `payments-dashboard-table-system-errors` (`SystemErrors`). The table is PAY_PER_REQUEST; these metrics emit only when a throttle/system error occurs.
+**DynamoDB** (`PaymentsDashboard` table, `TableName` dimension, Sum > 0): `payments-dashboard-table-read-throttle` (`ReadThrottleEvents`), `payments-dashboard-table-write-throttle` (`WriteThrottleEvents`). The table is PAY_PER_REQUEST; these metrics emit only when a throttle occurs. `SystemErrors` is intentionally not alarmed because it does not emit at the `TableName`-only dimension.
 
 **API Gateway** (implicit HTTP API v2 `ServerlessHttpApi`, `ApiId` dimension): `payments-dashboard-api-5xx` (`5xx` Sum > 0), `payments-dashboard-api-4xx` (`4xx` Sum > 10, client-error noise floor), `payments-dashboard-api-latency-p99` (`Latency` p99 > 3000 ms).
 

template.yaml

@@ -652,11 +652,13 @@ Resources:
         - !Sub arn:aws:sns:${AWS::Region}:${AWS::AccountId}:site-alerts
 
   # ── DynamoDB alarms (Wave 1, SCOPE-CONFIRM) ────────────────────────────────
-  # AWS/DynamoDB throttle/system-error metrics for the PaymentsDashboard table.
-  # These metrics emit at the TableName dimension and only on the occurrence of
-  # a throttle/system error — none are currently present in CloudWatch (the
-  # table is PAY_PER_REQUEST, so sustained throttling is unlikely but possible
-  # during burst-capacity ramp). Threshold > 0, Sum over 5m, ALARM-only.
+  # AWS/DynamoDB throttle metrics for the PaymentsDashboard table. These metrics
+  # emit at the TableName dimension and only on the occurrence of a throttle
+  # event — none are currently present in CloudWatch (the table is
+  # PAY_PER_REQUEST, so sustained throttling is unlikely but possible during
+  # burst-capacity ramp). SystemErrors is intentionally not alarmed: AWS/DynamoDB
+  # SystemErrors does not emit at the TableName-only dimension, so it can never
+  # fire. Threshold > 0, Sum over 5m, ALARM-only.
   DashboardTableReadThrottleAlarm:
     Type: AWS::CloudWatch::Alarm
     Properties:
@@ -695,25 +697,6 @@ Resources:
       AlarmActions:
         - !Sub arn:aws:sns:${AWS::Region}:${AWS::AccountId}:site-alerts
 
-  DashboardTableSystemErrorsAlarm:
-    Type: AWS::CloudWatch::Alarm
-    Properties:
-      AlarmName: payments-dashboard-table-system-errors
-      AlarmDescription: PaymentsDashboard table returned server-side (5xx) errors
-      Namespace: AWS/DynamoDB
-      MetricName: SystemErrors
-      Dimensions:
-        - Name: TableName
-          Value: !Ref DashboardTable
-      Statistic: Sum
-      Period: 300
-      EvaluationPeriods: 1
-      Threshold: 0
-      ComparisonOperator: GreaterThanThreshold
-      TreatMissingData: notBreaching
-      AlarmActions:
-        - !Sub arn:aws:sns:${AWS::Region}:${AWS::AccountId}:site-alerts
-
   # ── API Gateway (HTTP API v2) alarms (Wave 1, SCOPE-CONFIRM) ────────────────
   # AWS/ApiGateway v2 metrics on the implicit ServerlessHttpApi (ApiId dim).
   # v2 metric names are 4xx/5xx/Latency (not 4XXError/5XXError). 5xx and Latency