Return one deploy's status plus a byte window of its stored log.

The log bytes come from the deploy's deploy_log_chunks rows — contiguous, line-aligned slices with stored start_offset / byte_len byte accounting, so every window figure is byte math over stored lengths, never len(str) over decoded text.

With no offset the window is the LAST max_bytes bytes of the log, advanced past the first newline inside the window so the log starts on a whole line. The snap runs only when at least one byte follows that newline; when the newline ends the window, the raw window is returned unsnapped so the reply is never emptied. An explicit offset reads byte-exactly from that offset with no line snapping; an offset past the end of the log clamps to the log size and yields an empty log. window_bytes is the byte length of the returned window before utf-8 decoding: the next page starts at offset + window_bytes, and offset + window_bytes == log_bytes means the reply reaches the end of the log. A window boundary can still split a multibyte character (errors="replace" covers the decode), exactly as the file implementation did. A deploy with no chunks yet (a queued deploy) answers 200 with an empty log and log_bytes=0 — 404 stays for a missing or foreign deploy row only. A superseded deploy answers 200 too, with superseded_by naming its successor: its log is empty when a newer request replaced it in the queue, or partial plus one marker line when a planned stop superseded it mid-run. A reader paging a deploy whose chunks the sweeper prunes mid-pagination sees the remaining pages empty; the race is accepted, not defended — the log was already past retention.

The route only reads, so it runs on run_read_in_thread, and the whole answer costs one round trip: the access check, the deploy row, the log-size lookup, and one indexed range query over the chunks overlapping the window all run inside the same _load DB hop.