fix: complete + deterministic dedup candidate set on sync (GIT-70)

[nTEG-dev]

Base-retarget trail. This PR briefly pointed at main and was then retargeted back to feature/GIT-51-session-recovery.

Why: ci.yml triggers on pull_request: branches: [main], so a PR based on a stack branch matches no trigger and gets no CI at all — gh pr checks reported "no checks reported" for both #21 and #22. The stack tip contains every commit, so pointing #22 at main for one pass matrix-verified GIT-51 and GIT-70 on Node 18/20/22 together, then it was pointed back so the review diff stays the GIT-70 delta only.

Also worth recording: retargeting alone did not trigger CI. A base change fires pull_request: edited, and the workflow declares no types:, so it defaults to [opened, synchronize, reopened]. A close/reopen was needed to fire the run.

The durable fix — adding feature/** to the push triggers — is filed as a line item on GIT-45, not executed here: ci.yml is the release-path file and does not get edited mid-sprint.

Draft — verification only. Do not merge. Base is feature/GIT-51-session-recovery (stack tip), not main.

Third in the stack: PR #20 (GIT-69 + GIT-67/63) → PR #21 (GIT-51) → this. Based on the stack tip so the diff shows only the GIT-70 delta. Retarget as the stack merges.

The defect

An unordered limit: 200 single page feeding the text-dedup map in syncThreadsToSupabase, against a table already at 256 rows.

Every thread still synced — the per-thread lookup is an exact thread_id match, unbounded by the window. What truncated was dedup coverage. A text-matching row outside the loaded 200 meant the map missed it and a duplicate row was created, silently, with the dedup log never firing.

A write that fires because a read was incomplete. And because there was no ORDER BY, which 200 rows loaded was arbitrary — so whether a given close duplicated was nondeterministic between identical runs.

session_close now awaits this sync (GIT-69 item 3), so it runs synchronously on the close path.

Fix

1. Pagination via directQueryAll, which already existed — checked before building, same as the harness.
2. A deterministic total order (thread_id.asc). Required, not cosmetic: PostgREST Range pagination over an unordered result set can repeat and skip rows between pages, so without it the pagination would introduce the very gaps it was added to close. thread_id is unique, so it orders totally on its own.

directQueryAll stops at its maxRows cap without saying so. Inheriting that silence would rebuild the defect one layer up, so the cap is detected and reported.

Why coverage is a separate axis from success

dedup_coverage: "complete" | "partial" | "unavailable", with dedup_candidates so the claim is auditable. session_close surfaces it as a warning, not a failure.

Every thread syncs by identity regardless of coverage. Incomplete coverage means a duplicate may exist — which all_synced structurally cannot detect, because from the sync's perspective writing a duplicate is a successful write.

	detects	misses
GIT-69 item 3 gate	a thread that failed to sync	a thread that synced as a duplicate
this PR	the duplicate	—

The gate makes close honest about failures. This makes it honest about correctness.

Identity matching at the exact-thread_id lookup is untouched, per R8a.

Verification

Check	Result
npm run typecheck	clean
npm run build	clean
npm run test:unit	1093 passed
e2e GIT-67/63 acceptance	12 passed

New coverage (+5): deterministic order asserted at the call site; complete coverage past the old 200 window; cap reported as partial rather than absorbed; load failure reported as unavailable; sync still succeeds while coverage is incomplete. Four existing sync tests were updated — their mocks assumed directQuery for the candidate load and caught the change correctly.

Refs GIT-70, GIT-69, GIT-63