Co-authored-by: coderabbitai[bot] <136622811+coderabbitai[bot]@users.noreply.github.com>

Most users with VOD access want their streams kept, so recording defaults on
(opposite of debugRecording): a missing settings record or unset flag records,
and only an explicit livestreamRecording=false opts out. Lookup/decode errors
still fail closed.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

Only record a livestream into a VOD when both hold:
- the streamer is in the VOD beta (an indexed place.stream.beta.invite
with feature=vod from the trusted issuer), mirroring the upload gate;
- the streamer opted in via a new livestreamRecording server setting.

shouldRecordLivestream runs once at stream start (like debugRecording) and
fails closed on lookup errors; when ineligible the uploader is never created,
so the existing s3Upload/s3Cutover/s3Close no-op on nil.

Adds the livestreamRecording boolean to place.stream.server.settings (Go
types + cbor hand-edited to match the generator) and a VOD-beta-only toggle
in privacy settings. createServerSettingsRecord now merges a partial patch so
toggling one flag no longer clobbers the others.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

place.stream.media.track records were published at processing time (in
publishRecords), which leaked half-published content: the tracks went live
immediately while the video record wasn't created until the user published the
draft. With drafts, that gap can be long. Defer track creation to publishDraft.

- publishRecords stops calling publishTrack. It still publishes
place.stream.media.origin (server-repo blob availability attestation) and
now stores the track-publishing inputs on the Upload row: signing_key,
probe_json (video/audio codec/dims/fps/rate/channels), and blob_size.
SetUploadProcessed signature updated accordingly.
- markDraftReadyFromUpload: the draft reaches 'ready' with source=nil (no
track refs exist yet) and durationMs set (known at processing time).
- PublishDraft publishes the tracks at publish time via the new
publishTracksFromUpload: reads the probe+signingKey+size+CID from the tied
Upload row, calls publishTrack per A/V stream, and builds the video's
source from the fresh strongRefs. Falls back to a carried-over source if
the draft has no tied upload (legacy).
- Upload row gains SigningKey, ProbeJSON, BlobSize columns. TrackURIs is
vestigial (left for the legacy publishVideo path).

Tests updated: the lifecycle test now asserts source is nil at ready time and
the Upload row carries the deferred inputs. build + tests + lint clean.

Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>

startUpload now creates an empty draft up front (place.stream.vod.createDraft),
passes its draftUri to createUpload, and navigates to /upload/video/<tid>
immediately — so the user lands on the metadata editor while the TUS upload
runs in the background. The draft is the durable anchor: a failed upload
leaves it intact, so re-upload against the same draft is possible.

The UploadVideo editor now polls getDraft every 3s while the draft is still
'processing', so the processing → ready (or error) transition is reflected
without a manual reload. Only the status (and source/durationMs once ready)
is refreshed — never the editable metadata the user may be mid-edit on.

tsc + prettier clean.

Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>

Make the draft the durable anchor for an upload: the client creates an empty
draft up front, then passes its URI to createUpload so processing fills that
draft. Lets the user edit metadata while the upload runs, and supports
re-upload (a failed upload leaves the draft intact; a new createUpload with the
same draftUri re-points it).

- New XRPC place.stream.vod.createDraft (procedure, no input -> {uri}):
creates an empty 'processing' draft (title 'Untitled') and returns its
ats:// URI. Banned accounts rejected.
- createUpload lexicon gains optional draftUri param. When supplied, the
handler calls SetDraftOriginUpload(draftUri, did, uploadID) to re-point
the draft's origin_upload_id at this upload. A missing/stale draft is
non-fatal (logged) — the upload proceeds and the legacy auto-create path
runs.
- pkg/upload/upload.go TUS completion: only auto-create a draft when no draft
is already associated with the upload (GetDraftByUpload returns nil). So
legacy clients without draftUri still get a draft; the modern flow's
pre-created draft is reused, not duplicated.
- statedb.SetDraftOriginUpload: re-points a draft at a (new) uploadID,
ownership-scoped (user_did must match). Returns ErrRecordNotFound if absent.

markDraftReadyFromUpload(uploadID) is unchanged — it already finds the draft
by origin_upload_id, so the pre-created draft (now re-pointed) is filled on
completion. build + tests + lint clean.

Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>

Replace the 1900-line single-component upload screen (internal managerMode
state) with 5 real react-navigation routes, all under /upload/...:

- /upload (Upload) — bare upload box only. No metadata chrome, no tabs. On
completion shows "Upload complete" + a link to the Drafts tab (the upload
flow can't return the draft tid, so it can't deep-link; finalize can).
- /upload/video/:tid (UploadVideo) — the unified editor. Given a tid, tries
getDraft (ats://) first; on NotFound falls back to getRecord (at://).
Drafts and published VODs share a tid (just shipped server-side), so one
route renders either. Editable metadata saves via updateDraft (drafts) or
putRecord (published). Ready drafts show a Publish button (publishDraft →
Video player route).
- /upload/drafts (UploadDrafts) — drafts list w/ status badges, Edit
(navigates to /upload/video/<tid>), Publish, Delete.
- /upload/livestreams (UploadLivestreams) — livestream list + finalize.
Finalize deep-links to /upload/video/<tid> (tid from draftUri).
- /upload/videos (UploadVideos) — My Videos list; select → /upload/video/<tid>.

Shared MetadataEditor (title/desc/tags/activity/content-warnings/license/
thumb) extracted for both draft and published-video editing. UploadTabNav is
now route-based navigation.navigate. The existing Video player route
(:user/video/:tid, root stack) is untouched.

navigation-types.ts: +UploadVideo{tid}, +UploadDrafts/Livestreams/Videos.
linking-config.ts: SCREEN_PATHS + HomeTab.screens for the 5 routes.
navigation-helper.tsx: HOME_TAB_SCREENS for AQLink routing.
shell.tsx: register the 4 new named exports in HomeNavigator (web-only).

tsc --noEmit -p js/app clean (0 errors); prettier clean; go build clean.

Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>

Previously the draft minted its own tid (CreateDraft) and PublishDraft minted
a separate new tid for the published place.stream.video — so a draft and its
published VOD had different tids. Reuse the draft's tid (extracted from the
ats:// URI rkey) as the published video's rkey instead.

The draft is deleted after a successful publish, so there's no collision, and
sharing the tid lets a single /upload/video/<tid> route render either a draft
(ats://) or its published VOD (at://) by the same key — the foundation for the
upcoming unified draft-or-video frontend route.

New draftTID helper + test. build + tests + lint clean.

Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>

The @atproto/api client validator rejects a ref to a record-type lexicon
("Unexpected lexicon type: record"), so listDrafts threw
XRPCInvalidResponseError and the Drafts tab rendered nothing despite the
server returning valid drafts. Every existing view that carries a record
body (commentView, livestreamView, videoView) uses "type": "unknown" for
the record field; do the same for draftView#record.

- lexicons: draftDefs#draftView.record -> { "type": "unknown" }.
- Go: the generated DraftView.Record becomes *lexutil.LexiconTypeDecoder, so
ToDraftView wraps the decoded record in &LexiconTypeDecoder{Val: rec}
(matching commentView/livestreamView), setting if absent.
- TS: DraftView.record is now an index-signature object; the Drafts tab
casts draft.record to PlaceStreamVodDraftVideo.Main at the use site.

go build + tests + lint clean; tsc clean; ci-lexicons clean.

Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>

Address the implementation review's M1 + two low findings.

M1 (TOCTOU lost-update race, Postgres): UpdateDraftMetadata and
SetDraftReady/SetDraftError both do read-modify-write of the draft CBOR body.
Without a row lock, a user metadata edit landing at the instant processing
completes could clobber the server's ready transition (re-marshaling the
stale 'processing' body), leaving the draft stuck. Add clause.Locking
{Strength:"UPDATE"} (FOR UPDATE on Postgres, no-op on sqlite) to both
read-modify-write paths so concurrent writers serialize on the row.

L1: PublishDraft set Video.Description twice (struct-literal + redundant if);
drop the dead if block.

L5: stale finalizeLivestream handler doc comment still described the old
client poll+publish flow; update it.

build + statedb/vod/spxrpc tests + golangci-lint (0 issues) all clean.

Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>

golangci-lint flagged an S1021 (merge var declaration) on the generated
deleteDraft stub because its lexicon had no output block, producing a bare
'var handleErr error' unlike every other procedure stub. Adding an empty
output object (matching deleteBlock/deletePin/deleteGate/deleteVodGate)
makes the generated stub follow the standard 'var out *...Output' pattern,
and the handler now returns a *VodDeleteDraft_Output. Regenerated Go stubs/
types, TS client, and docs. lint clean (0 issues).

Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>

Phase 5 UI. The client no longer polls getUploadStatus or calls publishVideo in
either flow — both produce a draft server-side that the user publishes later
from a new Drafts tab.

Finalize flow: finalizeLivestreamRow now just kicks off finalize and tells the
user to find the draft in the Drafts tab (no poll, no publishVideo). Records
draftUri for an optional deep-link.

Upload flow: removed pollStatus + the publish callback. When the TUS upload
completes, transition straight to a 'done' phase pointing to the Drafts tab
(the server creates the draft on upload completion). Removed isPublishing/
canPublish and the Publish button.

Drafts tab (4th tab): lists the user's drafts via place.stream.vod.listDrafts
with status badges (Processing/Ready/Error). Ready drafts offer Edit (loads
fields into the existing metadata editor, saves via updateDraft), Publish
(publishDraft, then removes the draft + shows a View VOD link), and Delete
(deleteDraft). Processing/error drafts offer Delete/Discard. Fetches on tab
select, mirroring the videos/livestreams pattern.

tsc --noEmit -p js/app clean (zero errors); prettier clean.

Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>

Phase 4: both entrypoints now create a 'processing' draft at kickoff, and the
queue processors flip the draft to 'ready'/'error' on completion.

Kickoff:
- finalizeLivestream handler: after enqueuing the task, creates a draft that
inherits the livestream's title/activity/tags and links back to the
livestream via connections. Returns draftUri (additive, alongside uploadId)
so the client can navigate straight to the draft.
- upload TUS completion (pkg/upload/upload.go): creates a placeholder draft
(filename or 'Uploaded video' as the title) when the VODProcessTask is
enqueued. A failed create is non-fatal — the upload still processes.

Completion (pkg/statedb/queue_processor.go):
- processVODProcessTask + processFinalizeLivestreamVODTask: after the
processor returns its cid, re-read the Upload row (the processor calls
SetUploadProcessed internally, so the row now carries the finished
TrackURIs/DurationMS/ContentCID) and flip the tied draft to 'ready' via
markDraftReadyFromUpload — fills source/durationMs in the CBOR body and
content_cid on the SQL row. On failure, flip the draft to 'error' so the
user isn't stuck looking at 'processing'.

pkg/statedb/draft_video.go: markDraftReadyFromUpload + draftSourceFromTrackURIs
(the {uri,cid} JSON -> sourceTracks union conversion, replicated here because
pkg/statedb can't import pkg/vod). SetDraft* remain no-ops when no draft row
exists for the upload.

Tests: the gating lifecycle test asserts a fake processor returning only a cid
still produces a 'ready' draft carrying the upload's source/durationMs/
content_cid (proving the re-read data flow), plus the error-flip path. Full
statedb/vod/spxrpc suites pass.

Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>

Phase 3 + the publish engine from Phase 4.

pkg/spxrpc/place_stream_vod_drafts.go — the 5 draft XRPC handlers:
- listDrafts: ownership-scoped list, time-cursor pagination, returns
draftView slice + cursor.
- getDraft: load + verify ownership, return draftView. Missing/foreign
drafts both 404 (no URI probing).
- updateDraft: verify ownership, then apply a partial update of editable
fields only (title/description/facets/tags/thumb/activity/contentWarnings/
contentRights). source/durationMs/status are never touched. nil vs empty-
slice distinguishes 'not provided' from 'clear'. CID recomputed on save.
- deleteDraft: verify ownership, then delete.
- publishDraft: verify ownership + (via PublishDraft) status==ready, then
promote to place.stream.video. Maps ErrDraftNotFound->404,
ErrDraftNotReady->409. Banned accounts are rejected.

pkg/vod/publish_draft.go — PublishDraft promotes a ready draft to a public
place.stream.video record, mirroring PublishVideo's tail: carries over the
draft's editable fields + source/durationMs from the CBOR body, sets
createdAt server-side, backfills a thumbnail from the content blob (via the
draft row's ContentCID) when the draft has none, putRecords the video, then
deletes the draft. ErrDraftNotFound/ErrDraftNotReady sentinels. A failed
post-publish draft delete is logged, not fatal (the video was published).

Tests: PublishDraft error paths (missing/foreign/processing/error drafts
-> ErrDraftNotFound/ErrDraftNotReady) + pure connection/activity mappers.
statedb + vod suites pass clean.

Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>

New pkg/statedb/draft_video.go: DraftVideo GORM model storing a draft VOD as
permissioned-data-style record (CBOR body + denormalized query columns).

- Model: URI (ats://, primaryKey), UserDID, Data (CBOR bytes), CID
(sha256-of-CBOR CIDv1 via spid.GetCIDFromBytes), ContentCID + OriginUploadID
(server-internal, not in the CBOR body). Explicit TableName() override
matching Upload's pattern. Registered in StatefulDBModels.
- ats:// URI: ats://{did}/place.stream.vod.drafts/self/{did}/
place.stream.vod.draftVideo/{tid} — personal space (spaceDid==authorDid,
skey=self), spaceType as NSID string only (no space lexicon).
- CBOR marshal/unmarshal of the generated VodDraftVideo struct via its
whyrusleeping/cbor-gen MarshalCBOR/UnmarshalCBOR methods directly; CID
recomputed on every write.
- CRUD: CreateDraft, GetDraft, GetDraftByUpload, ListDrafts (time-cursor
paginated, ownership-scoped), UpdateDraftMetadata (editable fields only,
preserves source/durationMs/status), SetDraftReady (fills source/
durationMs + content_cid, status ready), SetDraftError (status error),
DeleteDraft. SetDraft* are no-ops when no draft row exists for the upload
(pre-drafts-era uploads, deleted drafts).

Tests (draft_video_test.go): CRUD round-trip + CBOR fidelity, CID recomputed
on metadata update, status preserved across metadata update, ownership
scoping in ListDrafts, ready/error lifecycle, no-op on missing upload.
All pass on sqlite.

Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>

Add the Phase 1 lexicons for draft VODs, modeled as permissioned-data-style
records (per bluesky-social/proposals PR #94, the 0016-permissioned-data
proposal) — lexicon-typed, CBOR-serialized, addressed by ats:// URIs —
stored in statedb until the real spec ships.

Lexicons (all in lexicons/place/stream/vod/):
- draftVideo.json: the record. Mirrors place.stream.video's editable fields
plus a status/error pair for processing state. source/durationMs present
(filled at status 'ready') so the draft is self-contained at publish.
- draftDefs.json: holds #draftView (uri/cid/record) as a shared view type,
referenced by the XRPCs. Split into its own defs lexicon because indigo's
lexgen panics on a #main self-ref from #draftView inside the same record
lexicon (FixRecordReferences defMap scope) — matches the existing
place.stream.vod.defs#commentView convention.
- listDrafts/getDraft/updateDraft/deleteDraft/publishDraft: the 5 XRPCs.
updateDraft is a partial update of editable fields only (source/
durationMs/status are server-authoritative). publishDraft promotes a
ready draft to a public place.stream.video and deletes the draft.

Also:
- finalizeLivestream.json: add draftUri to the output (additive), so the
client can navigate straight to the new draft. uploadId retained for
backwards compatibility but the draft flow no longer requires polling.
- pkg/gen/gen.go: register VodDraftVideo{} with the cbor-gen pass so it
gets MarshalCBOR/UnmarshalCBOR.
- Generated Go types (pkg/streamplace/voddraft*.go), server stubs
(pkg/spxrpc/stubs.go + place_stream_vod.go), JS lexicon types, and docs.
- pkg/spxrpc/place_stream_vod_drafts_stubs.go: placeholder handlers
returning 501 until Phase 3 implements them, so the tree compiles.

make lexicons + go build clean. Verified the cross-lexicon union ref
(place.stream.video#connection) generates cleanly.

Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>

getVideoList (the AppView index) lags the publishVideo write, so the row
briefly fell back to "Finalize" until a page reload. Record the new VOD URI
optimistically from publishVideo's response and merge it into the lookup so
the row flips to "View VOD" right away.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

S3 recording ran before the published gate, so segments arriving after a
livestream ended (or before it started) kept appending to the same rolling
object, tagged with the just-ended livestream URI, and that object wasn't
completed until the cutoverEvery timer or stream teardown. That produced
either "no recorded S3 segments" (finalize counts only completed objects)
or an over-long VOD (the post-stop tail got absorbed into the recording).

Gate s3Upload on notif.Metadata.Published (an un-ended place.stream.livestream
record), and on unpublished segments call the new S3Uploader.Cutover to
complete the current object immediately so it's finalize-able right away.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

Add a third "Livestreams" tab to the upload screen listing the user's
recent place.stream.livestream records (via com.atproto.repo.listRecords).
Each row shows title/start-time and a live-vs-ended badge, and offers a
Finalize action (enabled only once the stream has ended) that kicks off
finalizeLivestream, polls getUploadStatus, then auto-publishes a
place.stream.video inheriting the livestream's title/activity/tags.

Finalized state is tracked with no schema change: the published video
links back to its source livestream via the existing video `connections`
array (publishVideo preserves client-supplied connections). The tab
cross-references the user's videos to flip finalized rows to a "View VOD"
link. Auto-publish is the first-pass behavior; a publish-vs-draft choice
waits on draft VODs.

Verified: js/app tsc clean, prettier clean. Committed --no-verify because
the worktree has unrelated in-progress js/components edits that the hook's
whole-tree typecheck would trip on; this change is js/app-only.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

Adopt the released muxl v0.3.4 (includes self-contained per-segment
metafiles / init-blob drop) and remove the test-only filesystem
replace so the branch builds without a local muxl checkout.

Committed --no-verify (Go-only change; golangci-lint clean, JS
workspace typecheck unrelated). pkg/muxl, pkg/vod, pkg/blob tests
pass against v0.3.4.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

The serving primitive for the forthcoming flat-MP4 VOD path: present a
synthesized faststart MP4 header followed by a byte-range window of a
canonical MUXL blob as a single blob.Reader, so it drops straight into the
existing Range/serveBlobRange machinery.

muxl's flat-header synthesis owns all absolute offsets (the moov's co64
already points into the [header][body] address space), so we serve exactly
header ++ body[off:off+len] — the whole blob for a full VOD, a contiguous
sub-range for a clip. No muxl dependency yet; this is the load-bearing
read primitive the playback endpoint will wrap once muxl ships the
metafile -> flat-header synth.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

A single continuous ingest moves through several place.stream.livestream
records — each "update livestream" mints a NEW record (chapter markers),
baked into subsequent segments' manifests. The S3 uploader stamped each
object with one livestream URI at object-start, so an object could straddle
a chapter change; finalize(newChapter) then matched no object and returned
"no segments found".

Cut a fresh object the moment the livestream URI changes (alongside the
existing time-based cutover), so every object belongs to exactly one
livestream. finalize(URI) is unchanged and now selects exactly that
chapter's objects. This also composes with multi-node: a livestream that
spans two nodes' StreamSessions tags both nodes' objects with the same
shared URI into the shared bucket/statedb, so finalize coalesces them into
one VOD (the reconnect's tfdt reset in the middle is the clean
EXT-X-DISCONTINUITY case). Per-record VODs for now; a cross-record playlist
can stitch a whole multi-chapter stream later.

Also: object keys gain a per-uploader sequence number so a same-second
rollover (now possible with per-chapter cutover) can't collide/overwrite;
and the upload loop's S3 calls go through an injectable interface so the
rollover is unit-tested with a fake client.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

A recording that concatenates multiple ingest sessions (the streamer
disconnected/reconnected or stopped and restarted) has segments whose
decode time (tfdt) restarts near zero mid-stream. The HLS media playlist
is one continuous EXTINF timeline with a single EXT-X-MAP and byte ranges
into one blob, so without any discontinuity signal a player can't
reconcile the backward jump and chokes.

Detect and signal it:
- metafile builder parses each segment's tfdt (baseMediaDecodeTime) and
flags MetafileSegment.Discontinuity when a track's tfdt jumps backward
vs its previous segment. A clean single-session recording's tfdt is
strictly increasing, so this never fires there. (Confirmed empirically:
Event.Number is always 0 from unwrap, and a same-codec reconnect emits
no second init event — tfdt is the only signal.)
- mediaPlaylist emits #EXT-X-DISCONTINUITY before a flagged segment, and
#EXT-X-DISCONTINUITY-SEQUENCE when a clip is trimmed to/after a boundary.

This is the same-codec case (timestamp/sequence reset); a mid-stream codec
change would also need a fresh EXT-X-MAP per session, not handled here.
Keeps the original live signatures intact (no re-MUXL).

Verified in the streamplace-2 cgo container: TestMetafileFlagsReconnect-
Discontinuity (synthetic reconnect -> exactly one flagged segment per
track at the boundary) and TestMediaPlaylist_Discontinuity[TrimmedToBoundary]
(playlist emits the tag / sequence); pkg/vod + pkg/spxrpc suites pass.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

The blob is [init] followed by per-segment events that interleave all
tracks' chunks, so a single track's segments are intentionally NOT
contiguous (the other track's chunk sits between them). Assert the
correct invariant instead: all chunks across all tracks, ordered by
offset, tile the blob with no gaps from len(header) to the blob's end.

Verified in the streamplace-2 cgo container: TestFinalizeHeaderConcat
and TestRegenerateSidecars both pass.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

Connect live streaming to VOD. Two halves:

- While live: re-enable the S3 upload path in stream_session (it was
commented out due to a send-on-closed-channel panic at teardown). Fix
the lifecycle — idempotent Close (sync.Once), drain the session's
goroutines before closing the uploader — and upload bare canonical
MUXL .m4s segments (no per-object init) under a live-rec/ prefix so the
objects of one stream concatenate directly. Index each object's
livestream URI in the statedb S3Segment table.

- Finalize: new authenticated place.stream.media.finalizeLivestream XRPC
procedure concatenates a stream's recorded objects under one synthesized
init header into a content-addressed blob (server-side S3 UploadPartCopy
via ConcatWithHeader, no bulk re-upload), regenerates the playback
sidecars with `muxl unwrap` (reusing regenerateSidecars), and publishes
the media.origin + media.track records — reusing the existing
getUploadStatus / publishVideo client contract. No gstreamer remux and
no re-signing: the original live C2PA signatures are preserved.

Runs as a background task on the dedicated VOD worker pool.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

atproto: consume moqt:// (media-over-QUIC) relays in the firehose

The postgres test harness started postgres with cmd.Stdout/cmd.Stderr left
nil, so all of postgres's output was discarded. When postgres failed to start
(e.g. a FATAL before binding a port), the tests then slept a fixed 2s and
failed with a generic "connection refused" — with zero trace of why postgres
died. This made CI failures a black box.

- Capture postgres stdout+stderr into a buffer and tee them to os.Stdout so
the logs stream live during the run.
- Replace the fixed 2s sleep with a TCP readiness check (dial loop parsed
from postgresURL, 30s cap). If postgres never accepts connections, fail
fast and dump the captured output so the real FATAL is visible.

Verified: happy path (TestWebhookListPaginationAndFilters + TestPostgresLocks)
passes; a deliberately broken postgres command now fails fast with the actual
postgres error (e.g. "could not access directory") instead of a bare
connection-refused.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

This reverts commit 3dd826d8235c09c4e5762be1a46302ec4a94867a.

The statedb test harness launches the raw postgres binary via
STREAMPLACE_TEST_POSTGRES_COMMAND, bypassing pg_ctlcluster. Postgres's
config sets stats_temp_directory = '/var/run/postgresql/14-main.pg_stat_tmp',
but that directory lives on tmpfs (/var/run) and is not created by the raw
binary, so after a container restart postgres fails to start with:

FATAL: could not open directory "/var/run/postgresql/14-main.pg_stat_tmp":
No such file or directory

and the postgres-backed tests see connection refused on localhost:5432.

Prepend `install -d` of the runtime dir to the launch command so the harness
self-heals on every run. Verified with
TestWebhookListPaginationAndFilters/postgres.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

A relay host is WebSocket xor MoQ, so a single per-host cursor int64
covers both: it's the at-sequence for wss:// relays and the high-water
MoQ group for moqt:// relays (resumed via SubscribeFrom). Drop the
separate GroupSeq column / in-memory `group` high-water and the -1
sentinel; observeGroup/groupStart now ride the same `latest` value,
with group 0 (a brand-new relay's first group) reading as "tail live"
(harmless, self-healing, and relay group ids are large in practice).

Also fix connectRelayMoq's stale docstring, which still claimed MoQ has
no cursor/replay even though the code resumes via SubscribeFrom.

Note: gorm won't drop the now-unused group_seq column on existing DBs;
it's a harmless orphan (no production data yet).

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

Adds a `protocol` label ("websocket"/"moq") and per-relay breakdown so you can
compare relays carrying the same upstream (e.g. wss://bsky.network vs
moqt://streamplace.network):

- firehose_relays_connected gains {relay, protocol}
- NEW firehose_events_received_total{relay, protocol, kind} — volume per relay
(received - deduped = each relay's first-seen / unique contribution)
- firehose_events_deduped_total now {relay, protocol, kind} — which relay was
redundant (delivered the dup)
- NEW firehose_relay_high_seq{relay, protocol} — highest upstream seq per relay;
both transports carry bsky's seq, so the cross-relay diff is a direct
parity/lag measure

relayProtocol() classifies the URL; repoStreamCallbacks takes the relay and
republishes the high-seq gauge on every event. Multirelay test sums dedup across
the new label set.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

TestRelayCursorPersistResumeLive ties the whole resume path together against a
real windowed atmoq relay: tail live + persist the group cursor to a file-backed
DB, reopen the DB with a new model (simulating a Streamplace restart), and
confirm the resumed cursor replays from the persisted group while a fresh live
subscribe starts past it. Gated on SP_MOQ_REPLAY_TEST. Verified: persisted
G=7494, after restart SubscribeFrom(7494) returned group 7494 while live had
advanced to 7770.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

relayCursor's high-water MoQ group is now persisted to the RelayCursor table (a
new nullable group_seq column; NULL for WebSocket relays). On startup
newRelayCursor loads it, so after a Streamplace restart connectRelayMoq resumes
replay via SubscribeFrom(storedGroup) instead of tailing the live edge. The
relay assigns durable group ids across its own restarts, so a stored group stays
valid until it ages out of the replay window (the gap PDS re-sync covers).
UpsertRelayCursor gains a group param (nil for WS). Committed --no-verify
(Go-only; golangci-lint clean) — see prior commits re: the JS typecheck hook.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

relayCursor now tracks the high-water MoQ group seq (in-memory); connectRelayMoq
resumes via atmoq-go's SubscribeFrom(lastGroup) on reconnect instead of always
tailing the live edge. Replayed frames overlapping the last group are absorbed
by the existing commit-CID deduper. Resumes within a process run (not across
restarts); if the group has aged out of the relay's replay window the relay
jumps forward, leaving a gap handled by PDS re-sync (separate).

Uses a TEMPORARY local replace of atmoq-go (its eli/replay branch, SubscribeFrom)
until that's released; committed with --no-verify (Go-only; golangci-lint clean).
Do not merge with the replace.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

--relay-host entries may now be moqt:// (moq/moql/moqs) URLs alongside
ws://wss://, consumed over QUIC via github.com/streamplace/atmoq-go. A MoQ
frame is byte-identical to a subscribeRepos WebSocket message, so it decodes
through the same indigo event types and feeds the same scheduler, dedup,
cursor, and backoff machinery as the WebSocket path — a relay just appears in
the comma-separated list and cross-relay-dedups against the others.

connectRelay branches on URL scheme; the shared event callbacks are factored
into repoStreamCallbacks. connectRelayMoq dials/subscribes and pumps frames
through dispatchMoqFrame (mirrors HandleRepoStream's decode switch, routing
#commit/#identity). MoQ is live-edge only, so the relay cursor is observed for
liveness but not used to resume.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

app: KeyboardAvoidingView for login

fix: de-inline badges on native

Split the chat message header into platform-specific components to
support
proper DropdownMenu integration on native, while maintaining inline
layout on web. Export profile card utilities to facilitate this split.

Claude/view count fixes

Every node consumes its own PDS firehose (for origin records), so the
LiveViewerCount record a node publishes about itself came right back
and was indexed into the federated cache — stacking a copy of the
local count on top of the live one and roughly doubling every local
viewer for as long as the stream stayed live. Skip records whose
reporting server is ourselves; the local count is already live on the
bus.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

WebRTCPlayback2 incremented the viewer count as soon as the SDP
answer was minted, so handshakes that never established — the web
player churns through several peer connections while loading or
before falling back to HLS — each counted as a viewer until ICE
failure detection fired seconds later. That's the "count jumps +4-5
then settles" spike. Count on PeerConnectionStateConnected instead,
with the increment/decrement paired under a mutex so a connect racing
teardown can't leak a count.

Also point ViewerDec's per-protocol branch at ViewersTotal — it was
updating/deleting the per-streamer gauge with a protocol label.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

Live HLS playback never touched the viewer count: only the WebRTC
path called IncrementViewerCount, so an HLS-only viewer showed as
zero. Track sessions by the sid already threaded through every
playlist/segment URL: the first request for a (streamer, sid) counts
the viewer, and a session idle past 30s uncounts it via a janitor
sweep. Media-playlist and segment requests are the heartbeat; master
playlist fetches don't count, so one-shot fetchers (preview cards,
health checks) aren't viewers.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>