triage: add follow-up tasks for TASK-123 regressions (TASK-125, TASK-126)

Author: subtleGradient

.tasks/triage/TASK-125-fix-schema-alter-pk-to-key-rename.md

@@ -0,0 +1,37 @@
+# TASK-125: Fix schema_alter.zig pk→key column rename for clock table
+
+## Status
+- [ ] Planned
+
+## Priority
+high (blocks alter and merge tests)
+
+## Assigned To
+(unassigned)
+
+## Parent Docs / Cross-links
+- Caused by: `.tasks/done/TASK-123-fix-clock-table-schema-parity.md`
+- Test failures: `zig/harness/test-alter.sh` (Test 2b), `zig/harness/test-noops.sh` (Test 3)
+- Gap backlog: `research/zig-cr/92-gap-backlog.md`
+
+## Description
+TASK-123 renamed the clock table column from `pk` to `key` in `as_crr.zig`, but missed updating `schema_alter.zig`. This causes SQL errors when:
+
+1. **test-alter.sh Test 2b**: "table bar2__crsql_clock has no column named pk"
+2. **test-noops.sh Test 3**: "setWinnerClockCached failed" (SQL logic error)
+
+The issue is that `schema_alter.zig` still references `"pk"` in clock table SQL at:
+- Line 264: CREATE TABLE clock definition
+- Line 270: PRIMARY KEY clause
+- Lines 468-473: INSERT INTO clock
+- Lines 578, 590: INSERT OR REPLACE INTO clock
+
+## Files to Modify
+- `zig/src/schema_alter.zig` — update all clock table `"pk"` references to `"key"`
+
+## Acceptance Criteria
+- [ ] All `"pk"` references in clock table SQL changed to `"key"` 
+- [ ] Clock table creation includes `STRICT` and index (matching TASK-123)
+- [ ] `bash zig/harness/test-alter.sh` — 6/6 pass
+- [ ] `bash zig/harness/test-noops.sh` — 4/4 pass
+- [ ] No regressions in `make -C zig test-parity`

.tasks/triage/TASK-126-fix-merge-resolution-parity.md

@@ -0,0 +1,42 @@
+# TASK-126: Fix merge resolution parity with oracle
+
+## Status
+- [ ] Planned
+
+## Priority
+medium
+
+## Assigned To
+(unassigned)
+
+## Parent Docs / Cross-links
+- Test: `zig/harness/test-oracle-parity.sh` (Test 3a, 3b)
+- Test: `zig/harness/test-parity.sh` (ValueWin test)
+- Gap backlog: `research/zig-cr/92-gap-backlog.md`
+
+## Description
+The Zig implementation's merge resolution differs from the Rust/C oracle:
+
+**Test 3a: Remote wins with higher col_version**
+- Zig: returns "local" (local value kept)
+- Rust/C: returns "remote_winner" (remote value applied)
+
+**Test 3b: site_id tiebreaker (lower site_id wins on equal col_version)**
+- Zig: returns empty
+- Rust/C: returns "low_site"
+
+**ValueWin test (test-parity.sh)**
+- Expected rows_impacted = 1
+- Got: empty (merge not applied)
+
+This suggests the merge logic in `changes_vtab.zig` or `merge_insert.zig` is not correctly determining when remote wins.
+
+## Files to Modify
+- `zig/src/changes_vtab.zig` — merge resolution logic
+- `zig/src/merge_insert.zig` — merge helpers
+
+## Acceptance Criteria
+- [ ] `zig/harness/test-oracle-parity.sh` Test 3a passes
+- [ ] `zig/harness/test-oracle-parity.sh` Test 3b passes
+- [ ] `zig/harness/test-parity.sh` ValueWin test passes
+- [ ] No regressions in other parity tests