hierarchical con/duct collection/reporting

if I run overall con-duct over some long process but then additional more specific con-duct's within.

- I guess it also would not work "properly" ATM for reporting at the "root level" as children con-ducts would gain their own session ids, so root process will not count children processes (which is kinda like a feature if we solve next one):
- actually since we report wallclock -- that is shown ok:
```bash
❯ duct bash -c 'sleep 1; duct sleep 2'
...
❯ con-duct ls
PREFIX COMMAND EXIT_CODE WALL_CLOCK_TIME PEAK_RSS
.duct/logs/2026.02.22T10.59.16-1723653_ sleep 2 0 2.001 sec 2.2 MB
.duct/logs/2026.02.22T10.59.15-1723650_ bash -c sleep 1; duct sleep 2 0 3.082 sec 23.0 MB
```
- when child process runs we need to inform parent process, so it would know to look/collect stats from children processes
- I think it still remains useful to separate child from parent
- also worth considering triple- and further nesting of `duct` invocations, so solution should be generic.
- implementation idea(s):
- child process after detecting running in parent one, would inform the parent by placing its `{parent_output_prefix}_child-{pid}_info.json` upon start and finalizing upon completion with its summary
- we need to add storing `session_id` within out `_info.json` files. and if we detect that runs within some other duct, storing its `parent_session_id`.
- this should be sufficient to reconstruct full tree of invocations
- have an option for "full archival of inherited children stats" to place also its other files (`_stats` and outputs) there as well. (note that then we would require rewriting the corresponding _info.json to reflect placement and renaming of those files which is not needed in default case)
- `con-duct ls` then could report "own" and "total" time in case of children sessions, and also number of children sessions and depth (after analysis).
- `-r` could then list their details explicitly