Rebase id collisions on tsk git-pull
When two clones offline both pick the same id and create different
tasks at it, pull now resolves the collision automatically by
renumbering the loser past the highest known id on either side and
rewriting every reference.
Detection: at the start of the pull reconcile pass, scan the post-fetch
shadow for tasks/<id> or archive/<id> refs that exist on both sides at
different OIDs. Compare the `created` log line byte-wise — if equal
it's the same task edited in two places (regular conflict path); if
different it's an id collision. Earlier `created` timestamp keeps the
id; tie-break on lexicographically-smaller blob OID.
Renumber actions:
- LocalLoser: move our blobs (tasks/archive/attrs/backlinks/log) from
<old> to <new>; rewrite [[tsk-<old>]] across our task content, attrs,
log details, backlinks, and index titles; rewrite [[<our-ns>/tsk-<old>]]
across every other namespace's blobs; bump our `next` past <new>.
After this, our <old> is vacated and the regular reconcile pass takes
remote's <old> normally.
- RemoteLoser: copy remote's <old> blobs from the shadow to our local
<new> (preserving bucket); add to the index if it was active on the
remote; suppress reconcile for the remote's <old> blobs so they don't
clobber our local winner.
In both cases a `renumbered\tfrom tsk-<old>...` log entry is appended
on <new> via the existing per-task log so history is recoverable.
Also: `next` is now mergeable (take max of either side) so two clones
calling next_id offline don't deadlock on a non-FF push of `next`.
Test simulates both cases: A creates tsk-1, B sleeps 2s and creates
tsk-1 with a referencing tsk-2, B pulls. Asserts tsk-1 = A's content,
B's original moved past tsk-2, B's body link rewritten, and a
renumbered log entry exists on the new id.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>