089 task delete side effects: Flow PT REST finding

Q What does deleting a Task in the middle of a dependency chain do to its dependencies, its neighbours' dates, and the Version and PublishedFile that point at it? Does revive put them back?

Endpoint DELETE /entity/tasks/<id> ; POST /entity/tasks/<id>?revive=1 ; GET /entity/<type>/<id> ; POST /entity/published_files/_search

Docs claim Silent on side effects. The 204 has no body.

Actual

a -FS-> b -FS-> c; Version.sg_task = b; PublishedFile.task = b
before     a 03-02..03-03 down=[b]   b 03-04..03-05 up=[a] down=[c]   c 03-06..03-09 up=[b]
DELETE /entity/tasks/b -> 204, 0 bytes
after      a 03-02..03-03 down=[]    b 404                            c 03-06..03-09 up=[]
           both TaskDependency rows: GET 404; _search with options return_only=retired: both
           Version 200 sg_task=null   PublishedFile 200 task=null   _search ["task", "is", b]: 0
PUT a due_date 03-10 -> 200          a 03-02..03-10   c 03-06..03-09 (no longer follows)
POST /entity/tasks/b?revive=1 -> 200 {"did_revive": true}
after      a 03-02..03-10 down=[b]   b 03-11..03-12 up=[a] down=[c]   c 03-13..03-16 up=[b]
           both TaskDependency rows: GET 200
           Version sg_task=b   PublishedFile task=b   _search ["task", "is", b]: 1

Teaches

linked to the deleted Task	after `DELETE`	after revive
its TaskDependency rows	retired: 404 on `GET`, listed under `return_only: retired`	live again
the upstream and downstream neighbours	unlinked from it; not linked to each other	relinked
the neighbours' dates	unchanged	the chain rescheduled from the upstream's current dates
`Version.sg_task`	`null`; the Version stays	the Task again
`PublishedFile.task`	`null`; the file stays	the Task again

A PublishedFile loses its Task and nothing says so. The file stays live with task null, so a ["task", "is", ...] query stops finding it and the publish reads as an orphan. Read what points at a Task before deleting it; the 204 names nothing.
The chain is cut, not bridged. c stopped following a: moving a afterwards left c where it was. A sync that removes a middle Task must write the a -> c dependency itself if it wants one.
Revive is a full undo on the links measured here: dependencies, sg_task and task all returned with the same row ids. The revived chain is rescheduled at once, so its dates are not the ones it was deleted with.
A delete request inside _batch does the same to the Task, its dependency rows, its neighbours and Version.sg_task, and revive undoes it the same way (probe 103). PublishedFile.task was not measured on that route.
Deleting a Task retires only the Task and its dependency rows, unlike deleting a Shot, which retires its Versions (probe 060).