Log.Append advances LastSeq() past a write that never lands, so a resuming viewer's cursor reads as answerable when Since() has nothing there

[AmirF194]

eventlog.Log.Append increments l.last before it writes anything. If the write or flush fails partway, the error goes back to the caller, but the sequence counter already moved: LastSeq() reports a seq that was never persisted and never added to l.entries.

Session.Attach trusts since <= LastSeq() as proof the log can answer a resume (session.go:138). When the failed Append happens to be the most recent one, Since(since) returns zero entries across that gap instead of erroring, so the documented snapshot fallback never fires and a reconnecting viewer opens on silence: no screen, no new output.

Reproduced it with a white-box test in internal/eventlog: append one entry, close the underlying file to force the next write to fail, then check LastSeq() and Since(0).

eventlog_test.go:112: LastSeq() after failed Append = 2, want 1 (unchanged)

Only one entry ever reached entries, but LastSeq() had already moved past it. Same write-failure class (disk full, EIO) session.go's own onOutput comment already tolerates elsewhere, just not this path. PR with the fix and the regression test to follow.