Merge branch 'worktree-agent-adf34e265d2dcae96' into arch-review-remediation

docs/requirements/Component-AuditLog.md

@@ -305,6 +305,24 @@ per-row / per-entry path — so the documented invariant that one bad row cannot
 sink the rest of the batch still holds, it is simply no longer paid for on the
 healthy path.
 
+The set-based path binds its string parameters at the VALUE's own length, never
+at the column width. Declaring the width makes the client TRUNCATE an over-long
+value at bind time and commit the shortened row — silent mutilation in an
+append-only store, with no `PayloadTruncated` flag to admit it, and inconsistent
+with the per-row and reconciliation paths, which send the value in full and let
+the server reject it. Length enforcement belongs to the server on every path:
+reject everywhere, truncate nowhere. (Deliberate, policy-driven truncation of
+`RequestSummary`/`ResponseSummary` under the payload caps is a different thing
+entirely — it happens before the write and always sets `PayloadTruncated`.)
+
+The per-row fallback runs on its OWN short cancellation budget rather than the
+batch's. Sharing it meant that a batch failing *because* the ingest budget
+expired handed every fallback insert an already-cancelled token: N instant
+failures, N counter bumps, nothing accepted — the fallback defeated at exactly
+the moment it was needed. A blown budget is also counted ONCE for the batch
+rather than once per row, so the health counter reads as one timeout instead of
+a burst of write failures.
+
 **Timeout ladder.** The ingest budget is deliberately the smallest on the path:
 the site's Ask and the central gRPC handler's Ask are both 30 s, the actor's
 own database budget is 20 s and the per-statement SQL timeout is 15 s. Before