[HanielUlises]

Nothing written below a sensing action started before its outcome was known, even when the outcome had no bearing on it. In the two-site survey, the south scan waited for the north one to be read, although it appears under both of its outcomes.

schedule_policy rearranges a policy before it is rendered:

• An action moves above its parent when the two are independent and it could start earlier. Its earliest start is the end of the latest action above it that it depends on, by declared duration. It may move above a branch only when every branch begins with it, and the branch is then copied under each of its outcomes. Swapping two independent actions leaves both earliest starts unchanged, so the rearrangement terminates. It gives up past 20 000 nodes and falls back to parallel_groups.
• A chain of pairwise independent actions runs as one Parallel, and members may now branch. Their outcomes then choose the continuation, one switch per member, with a copied member reading the outcome of the one that ran.

Independence uses the same test as parallel_groups, now exposed as may_overlap. policy_to_bt with groups is now this renderer given the policy as written. Its XML is byte-identical to rolling on the test policies, with and without groups.

Two-site survey, measured locally (the same figures on two runs):

dispatch	groups	declared	measured
serial	none	18 s	22.5 s
parallel	drives; scans	11 s	15.0 to 15.5 s, all four outcome combinations

Before this change the parallel groups were the drives and then the north report beside the south scan, 12 s declared. 11 s is the minimum here: both reports go to relay, so they run one after the other.

policy_schedule_test runs every outcome combination through the schedule and checks that it runs the same actions as the written policy, in four steps.

Unrelated, and on rolling too: survey_sites_actions sometimes dies at shutdown (SIGSEGV/SIGBUS) on the host after the mission completes. It didn't happen in the Docker image.