TaskStatus.started() being a no-op if cancelled can cause deadlocks

TaskStatus.started() starts with the logic:

        # If the old nursery is cancelled, then quietly quit now; the child
        # will eventually exit on its own, and we don't want to risk moving
        # children that might have propagating Cancelled exceptions into
        # a place with no cancelled cancel scopes to catch them.
        assert self._old_nursery._cancel_status is not None
        if self._old_nursery._cancel_status.effectively_cancelled:
            return

However, this logic does not hold if the function calling started() then proceeds to do its work in a shielded cancel scope. This describes trio-asyncio, and caused the deadlock reported in https://github.com/python-trio/trio-asyncio/issues/115.

trio-asyncio can work around this by shielding the call to start(), but maybe Trio could also reconsider the logic in started()? I think at minimum it's safe to move the task if the new nursery is also effectively cancelled. It should also be safe to move the task if no Cancelled exception has actually been raised yet, but that's hard to track and maybe not worth it?

Start by reading TaskStatus.started() and the cancellation and nursery handling around its early return. Compare the behavior with the deadlock described in trio-asyncio issue 115, then determine and validate a safe rule for moving the task when cancellation and shielding interact; done means the deadlock scenario is resolved without violating cancellation semantics.