Repair retention response and update compatibility #8

Priority

p0 — Existing advertised methods fail against supported server contracts; this is correctness, not a new feature request.

Gap

Sync/async retention.list() expects an envelope, but both server baselines return a bare array (or null when empty). Empty execution history is executions:null, which is iterated directly. Released Arc requires database on update; the SDK signature cannot supply it. Main instead supports partial updates. None of PRs #2/#3/#5/#6 changes these modules.

Evidence: SDK retention, released server, main server. Unchanged-method fixtures reproduce array/null failures in both modes; no full SDK/server pass is claimed.

Acceptance

• Accept populated arrays, empty arrays/null, and null execution histories.
• Define and test released/full-definition versus main/partial-update compatibility without resending stale state unnecessarily.
• Distinguish omitted, explicit clearing, false and zero values; validate database handling.
• Expose retention skipped/cold omission diagnostics when returned.
• Add regressions through public SDK calls and run against both pinned server baselines.

Tracking: https://github.com/Basekick-Labs/ops/issues/40. Analysis baselines: SDK main 46d3b66 and pending PRs #2/#3/#5/#6; Arc release e83bb1e (v26.09.3) and main a63f4a8. Implementation is unscheduled; the parent analysis deadline is 2026-10-30. No owner or delivery commitment is implied.

Verification must record exact versions/commands/results and separate Manual Test from IA Test. Require sync/async cases, negative authorization/validation cases, and existing-regression preservation. Local Docker is appropriate for end-to-end server checks; inventory and clean up only test resources.