Recall the aircraft of this farm. The phone's ABORT button ends here.

THE DEVICE IS RESOLVED, NEVER SUPPLIED. Same rule as the customer mission route: a phone naming its own target could recall somebody else's aircraft by typing a different id. The farm's one active N100 is looked up here; two of them is a 409 and none is a 404, because guessing which to recall is not a thing software should do.

WHAT HAPPENS NEXT, so the shape of this handler makes sense: the row is published retained to the dock, whose supervisor holds it as STATE -- not gated on preflight, not gated on the aircraft being airborne -- and dock-mav then sends BRUMBY_DOCK_ABORT at 1 Hz for as long as it stands, deliberately even into a link that reads stale. The Cube changes its own flight mode on receipt and flies the recovery itself. So this endpoint's job is only to make the standing instruction exist; nothing downstream is waiting on this response.

THE IDEMPOTENCY KEY IS REQUIRED, for the reason the admin route gives: a retried POST without one places a second intent with a second id, and two rows are two recalls. Here it also matters in the other direction -- a panicking operator pressing ABORT four times should place ONE recall, not four.