There's a strong analogy here to regular processes and daemons, or Task and Task.detached, etc - lots of precedence in comparable systems for supporting both modes, because there's plenty of very good use cases for each.
The safer default is to cancel the subprocess when the controlling task / job / actor / whatever terminates. If that's not the intended behaviour, it's more likely to be discovered during testing than the converse, and it's less likely to cause abandoned, resource-wasting processes.
This behaviour could be selectable via a parameter at initialisation time (Subprocess.run in your current design) or something done later (e.g. a detach method). Deferring the decision provides some flexibility; it supports cases where it's not known whether the subprocess should be cut loose until after some interaction with the subprocess.
It is potentially complicated, however, by the multiple layers - there's the question of what to do when the owning Subprocess goes away, but also when the owning process goes away.