template task linked twice

Q Two Tasks on one Shot both point template_task at the same template task X (a conflict loser left linked). When the Shot's task_template is cleared then set to T (recipes 015, 020), are both re-synced (probe 102), is anything created, which one gets T's edges to X's neighbours, and does anything error?

Endpoint POST /entity/tasks ; PUT /entity/shots/<id> ; POST /entity/tasks/_search ; POST /entity/task_dependencies/_search

Docs claim Silent.

Every precondition is provisioned by the probe (template, Shots, Tasks, edges); no operator step.

Actual

T: w, x (est 600, desc T.x), y; x on w, y on x finish-to-start-next-day
xa, xb: both POSTed with template_task=T.x, est 60, desc hand; xa first (lower id)
Shot1 xa, xb only.  Shot2 the same, xb created_at 2020 and sorting first by content.
Shot3 control: one Task x1.  Shot4 xa, xb, plus w, y linked to T.w, T.y; y on xb, xb on w made by hand
every Shot: PUT task_template null -> 200, nothing changes; PUT task_template T -> 200
run 3 (committed probe), after T:
  Shot1  xa content=x est=600 desc=T.x | xb x_b 60 hand   + w, y created   xa on w, y on xa
  Shot2  xb content=x est=600 desc=T.x | xa x_z 60 hand   + w, y created   xb on w, y on xb
  Shot3  x1 content=x est=600 desc=T.x                    + w, y created   x1 on w, y on x1
  Shot4  xb content=x est=600 desc=T.x | xa x_a 60 hand   nothing created  y on xb, xb on w kept (same ids)
the re-synced one, 6 runs (the first 2 from a draft with the same calls; run 1 had no Shot4):
  Shot1 (xa lower id, older)           xa xa xa xb xb xb
  Shot2 (xb older, earlier by name)    xa xa xb xa xb xb
  Shot4 (edges already on xb)           - xb xb xa xb xb
Shot4 when xa was picked (run 4):
  xa content=x est=600; edges: y on xa, xa on w created; y on xb deleted; xb on w kept
left clean, every run: 0 Tasks, Shots, TaskTemplates zzprobe_106*, 0 of the TaskDependency rows seen live

Teaches

• One Task per template task is re-synced and wired, the others are skipped. The skipped one keeps its content and fields, still points at X, and gets no edge. No second X is created; w and y are created only when nothing links to them. Every PUT is 200.
• Which one wins is not predictable from the caller's side. Across 6 runs the pick flipped on identical setups: not the lowest id, not the oldest created_at, not the first by content, and not the Task already holding T's edges (Shot4 run 4).
• When the other Task wins, the loser's edges, both of T's shape, are handled unevenly: y on xb was deleted, xb on w was kept, and the winner got both. Measured once; the cause is not measured.
• Before an apply, leave at most one Task per template task linked: unlink or re-point the others (template_task null), or the result depends on the server's pick. Recipe 015's key caveat can produce this state (probe 096 made it by hand).