batch delete revive

Q Does a delete request inside POST /entity/_batch retire the row the way DELETE /entity/<type>/<id> does, so that revive brings it back with the same id, fields and links? Measured for a Task and for a TaskDependency.

Endpoint POST /entity/_batch ; DELETE /entity/<type>/<id> ; POST /entity/<type>/<id>?revive=1 ; GET /entity/<type>/<id>?options[return_only]=retired ; POST /entity/<type>/_search

Docs claim Silent on whether a batch delete retires. Recipe 002 measured only that GET 404s after it.

Actual

a, b, c; edge b on a (default type); edge c on a start-to-start +2; Version.sg_task = b
Each row goes through the batch delete, then revive, then DELETE (the control), then revive.
Task b                          _batch delete                   DELETE (control)
  response                      200 {"request_type": "delete",   204, 0 bytes
                                "type": "Task", "id": b,
                                "uuid": "...", "did_delete": true}
  GET b                         404                             404
  retired: _search, GET         [b], 200                        [b], 200
  edge b on a                   GET 404, listed retired         GET 404, listed retired
  a.downstream_tasks            [c]                             [c]
  Version.sg_task               null                            null
  revive b                      200 {"did_revive": true}        200 {"did_revive": true}
  after revive                  same id; content, dates, description, status, entity, project,
                                upstream_tasks equal to before; edge b on a live, same fields;
                                a.downstream_tasks [b, c]; Version.sg_task = b     (both routes)
TaskDependency c on a
  response                      200 {..., "type": "TaskDependency", "did_delete": true}   204
  GET row                       404                             404
  retired: _search, GET         [row], 200                      [row], 200
  c.upstream_tasks              []                              []
  revive row                    200 {"did_revive": true}        200 {"did_revive": true}
  after revive                  same id, start-to-start, offset_days 2, c.upstream_tasks [a]  (both)
negative control: a live row in the same retired reads -> _search omits it, GET options 404, every time
left clean: 0 Tasks, Shots, Versions zzprobe_103_*, 0 TaskDependency rows on a, b, c

Teaches

• A batch delete is a retire, not an erase. Every read-back matched the plain DELETE: the row lists under return_only: retired by _search and by GET options[return_only]=retired, and POST /entity/<type>/<id>?revive=1 answers did_revive: true.
• The side effects of deleting a Task (probe 089) are the same on both routes: its edges retire with it, the neighbour's link drops, Version.sg_task reads null, and revive restores all of it with the same ids.
• An undo stack can record the ids a batch delete returns (data[i].id) and revive them one by one; recipe 018 applies to a batch-deleted edge unchanged.
• Not measured: revive inside _batch (it accepts only create, update, delete, recipe 002), a Task and its edge deleted in the same batch, and a PublishedFile link.

The probe provisions every row it reads; no operator step. It runs each row through the batch delete first and the DELETE control second, on the same row, with a full read-back between steps.