docs(events): document durable thread seq watermark

[yu1128-L]

Why

backend/docs/RUN_EVENT_STREAM.md is the public contract for seq, but it
stopped at "monotonic within a thread" and never described the durable
watermark added in #6477 (fixing #6471). External consumers reading only this
doc cannot learn that the guarantee now survives run deletion, which is exactly
the case that used to break after_seq pagination.

What changed

The Record Envelope section now documents that the database store keeps a
per-thread high-water mark (run_event_thread_seq) independent of the event
rows: deleting a run never lowers the next allocated seq, values are not
reused within a thread, and an already-advanced after_seq cursor does not
miss later events. It also notes that thread deletion drops the mark only when
no events remain for the thread across every owner and category.

Surface area

• Docs / tests / CI only — no runtime behavior change

Validation

Docs-only. Verified the wording against
backend/packages/harness/deerflow/runtime/events/store/db.py
(_max_seq_for_thread, _raise_seq_watermark, delete_by_thread) and the
internal runtime/AGENTS.md watermark note. No code or test behavior changed.

AI assistance

Tool(s) used: Codex

How you used it: Drafted the paragraph from the merged #6477 behavior and
the store code; I reviewed the result against db.py.

• I've read and understand every line of this change and take responsibility for it — it's not unreviewed AI output.

[willem-bd]

Docs review at 3aa27b9: the new paragraph is accurate against the head implementation. run_event_thread_seq is a per-thread table independent of run_events (backend/packages/harness/deerflow/persistence/models/run_event.py); _max_seq_for_thread allocates from max(row max, watermark); delete_by_run raises the watermark to the thread-wide max inside the mutation fence; delete_by_thread drops it only when an unfiltered (all-owner, all-category) EXISTS finds no surviving rows — so "deleting a run never lowers the next allocated seq" and the owner/category wording both hold. I also checked the bundled frontend test change against formatWithViewerTime and the three test.each expectations are correct for the pinned clock. One process finding inline: that test change is not described in the PR body.

[willem-bd]

The PR body's "What changed" covers only the RUN_EVENT_STREAM.md paragraph, but this also rewrites the test's clock handling — worth a sentence in the description (or a separate test-only PR) so the docs-only framing matches the diff.

The change itself looks correct and worth keeping: the fixture is pinned to 2026-10-07 and the old regex /01:00 \u00b7 (?:\S+ )?09:00 your time/ stops matching once the real clock moves more than a day past that date, because the viewer part then renders as the two-word absolute form Oct 7 09:00, which the single optional \S+ cannot cover (the old comment only considered the \u00b11-day cases). Faking Date in beforeEach and pinning each case's now makes all three relative-day paths deterministic instead of rotting with the wall clock.