A clip and logs for the test that failed

No, and this surprises people, so plan for it. Recording starts in session mode because we cannot know whether your suite marks tests; the first boundary we receive discards the session recording and switches to one recording per test. A marked run produces clips and no session file. There is no cutting step that could produce one from the other afterwards.

There is nothing to detect. A session is a stream of browser commands, and nothing in that stream distinguishes the end of one test from the start of the next. Test boundaries exist only in your code, so they have to be sent in band.

No. Both come from the browser's own debugging protocol — CDP on Chrome and Edge, WebDriver BiDi on current Firefox — so no code is added to your suite. Safari exposes neither protocol and therefore has no console or network capture on any entrypoint, with any vendor.

No — a per-test clip is the test itself, so failures that happen between tests, in setup or teardown, fall outside it. On a short suite where the interesting failures live there, an unmarked run and its single session recording tells you more than slices do.

That is the case a recording handles worst, because the video ends at the timeout showing a screen that is not moving. Live View is the better tool there: you can watch the run as it happens and see what it is waiting for, rather than reconstructing it afterwards.

Thirty days, on every plan, after which they are removed automatically. That is long enough to investigate a failure and close the ticket; anything you need for longer should be downloaded.