093 clear dates pin: Flow PT REST finding

Q Does clearing start_date and due_date on a Task (writing both to null) pin it?

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

Docs claim Silent. entity_types/Task and probe 087 established that writing a dependent's own dates pins it; neither says whether a null counts as a write, or which date does it.

Actual Provisioned by the probe: one upstream up, five dependents on it (finish-to-start-next-day), all created 2026-03-02..03-03; the server then moved every dependent to 03-04..03-05. Each dependent gets one write, then up moves to 03-09..03-10. Controls sreal/dreal write a real date.

                         both        start       due         sreal       dreal
first read (linked)      pin=False   pin=False   pin=False   pin=False   pin=False
PUT each                 start,due   start=null  due=null    start=03-05 due=03-06
                         =null
after                    None..None  None..03-05 03-04..None 03-05..03-06 03-04..03-06
                         pin=True    pin=True    pin=False   pin=True    pin=False dur 960->1440
PUT up 03-09..03-10      held        held        03-11..03-12 held,      03-11..03-13
                         viol=False  viol=False  pin=False   viol=True   pin=False
PUT due due=03-20 (control, same Task)           03-11..03-20 dur=3840 pin=False
PUT due start=03-16 (control, same Task)         03-16..03-25 pin=True
PUT each pinned=false    03-11..03-12 03-11..03-12 03-11..03-20 03-11..03-12 03-11..03-13
                         all pin=False, viol=False
left clean: 0 Tasks, 0 TaskDependency rows

Teaches

write on a dependent Task	`pinned` after	on the next upstream write
`start_date` null, alone or with `due_date`	`true`	held; the null stays null, `dependency_violation` stays `false`
`start_date` real	`true` (control)	held; `dependency_violation` `true`
`due_date` null alone	`false`	follows: both dates rewritten from the upstream and `duration`
`due_date` real	`false` (control, twice); `duration` recomputed	follows, new `duration` kept
`PUT {"pinned": false}`	`false`	rewrites `start_date` from the upstream, `due_date` from `duration`

start_date is the pinning write, not "any date". The same Task (due) stayed unpinned after due_date null and after a real due_date, then pinned on a real start_date. A due_date write acts like a duration write (probe 100): it resizes, it does not anchor.
Nothing unpins a Task by itself: both and start stayed pinned with a null start across the upstream move. A null start raises no dependency_violation, so it is invisible to a violation check.
duration survives every null write (960 throughout); the unpin recompute uses it to refill due_date.
A sync that wants the server to reschedule a Task sets pinned: false; nulling the dates either pins it (start_date) or is overwritten at the next upstream write (due_date).