Reader.open_ leaks its descriptor when trace header parsing fails

`Trace.Reader.open_` opens a file descriptor and immediately passes it to `make_reader`:

```ocaml
let open_ ~filename = make_reader (Unix.openfile filename [ Unix.O_RDONLY ] 0)
```

`make_reader` parses the trace-info packet before returning the reader. A truncated or malformed trace can raise from that parsing path, and there is no reader value available for the caller to close. The descriptor opened by `open_` is therefore leaked each time this happens. A process that inspects multiple bad traces can eventually exhaust its descriptor limit.

The success path needs to retain ownership exactly as it does today. On the exception path, `open_` should close the descriptor best-effort and re-raise the original parsing exception. I have a focused patch ready for that cleanup.

Start at Trace.Reader.open_ and its call to make_reader, including the Unix.openfile entry point. Exercise the truncated or malformed trace parsing path and verify that the descriptor is closed while the original parsing exception is re-raised; confirm that the successful path still leaves ownership with the reader.

Written by the indexing model from the issue text.