Start and manage Temporal Child Workflows with the correct Parent Close Policy and awaiting-versus-detaching pattern

Documented steps

1. Choose the start API by whether you need to interact with the child while it runs. Python: `execute_child_workflow()` starts and awaits full completion in one call, while `start_child_workflow()` returns a handle you can signal or query without blocking. TypeScript: `executeChild()` versus `startChild()`.
2. Always await at minimum the start call itself, even when detaching. The `ChildWorkflowExecutionStarted` event must be recorded in history before the parent completes, otherwise you have no guarantee the child actually started.
3. To detach (fire-and-forget from the parent's perspective), use `start_child_workflow` / `startChild` to get a handle, optionally signal it, and simply do not await its completion.
4. Set the close behavior explicitly: Python `parent_close_policy=ParentClosePolicy.ABANDON`, TypeScript `parentClosePolicy:` in the child workflow options.
5. Know the three policy values: `Terminate` forcefully terminates the child, `Abandon` leaves it running unaffected, and `Request Cancel` sends a cancellation request the child's own code must handle.
6. Remember the default is `Terminate` in both SDKs. If you want children to survive or wind down gracefully after the parent finishes, you must override it per child.
7. By default children are scheduled on the same Task Queue as the parent unless you pass a different `task_queue` / `taskQueue` in the child options.
8. Mix policies per child as appropriate — for example abandon a fire-and-forget audit-log child while terminating a tightly coupled sub-process child of the same parent.
9. Reference docs: https://docs.temporal.io/parent-close-policy | https://docs.temporal.io/develop/python/child-workflows | https://docs.temporal.io/develop/typescript/child-workflows