Signed-off-by: Natalie Bridgers <natalie@stream.place>

bump to go 1.26.5

Go 1.26 deprecates direct access to ecdsa.PrivateKey.D, but the
suggested replacement (PrivateKey.Bytes) rejects non-NIST curves
like secp256k1. go-ethereum's crypto.FromECDSA does the same
32-byte left-padded scalar encoding and supports our curve.

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

Add stream.received webhook event

Smaller OAuth requests

The description under "Show when I'm live on Bluesky" overflowed the
login page on mobile with the keyboard open; move it into a hover
Tooltip like the live-dashboard checkboxes. The row's zIndex: -32
(cargo-culted from the buttons row) would have painted the tooltip
behind the handle input, so drop it — the typeahead overlays it
guarded against carry their own higher zIndexes anyway.

Localize the label and description into all seven supported locales;
it's the text that decides what users grant us, so it shouldn't be
English-only.

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

Adds a checkbox to the handle-entry screen (with a preview of the red
Bluesky LIVE avatar ring, since that's the headline thing being declined)
that requests an OAuth scope without the repo?collection=app.bsky.* write
grants. The read-only rpc:app.bsky.* scopes are kept for now; removing
them entirely (in favor of caching profiles/avatars ourselves) is a
follow-up.

Server side, sessions now track their granted scope via oatproxy (bumped
to the fable/dynamic-scopes branch, which accepts subset scopes at PAR
time, reports honest scope in tokens, and adds the RFC 7662
/oauth/introspect endpoint it always advertised):

- statedb.GetSessionByDIDWithScope scans a user's valid sessions for one
holding a grant, newest first; sessions from before scope tracking
count as full grants, so no data migration.
- The director's live-status writes (the red ring) pick a session with
the app.bsky.actor.status grant and quietly skip when the user declined
it everywhere; startLivestream skips the go-live post the same way.

The frontend learns its own scope from /oauth/introspect after login and
locks the "Create Bluesky post" checkbox when posting wasn't granted.

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

s3: uniform multipart parts for r2

liveConfig gated only on S3_ENDPOINT, so a CI environment that defines
S3_ENDPOINT for other purposes un-skipped the live tests and they died
with "static credentials are empty". Require endpoint AND access key
AND secret before running; anything less skips as intended.

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

Before, the first error anywhere in the upload loop (e.g. R2's InvalidPart
rejection at the first 10-minute rollover) killed the loop for the rest of
the stream: one error line, then segments backed up silently and nothing
more was recorded or logged. Production showed exactly this signature —
one "started S3 multipart upload …-1.m4s" per stream, one InvalidPart ~10
minutes later, then silence.

Now the loop recovers: the broken object is aborted (so the backend
doesn't hold its parts) and abandoned with a loud log including the key
and how many bytes are lost, and the next segment starts a fresh object.
One bad object costs a gap in the recording instead of the whole stream.
Abandoned objects never get RecordComplete, so finalize's
completed_at-only query skips them naturally. Only the final
completing flush still surfaces through Close — there are no more
segments coming to recover with. A failure with no object in flight
(CreateMultipartUpload itself) logs the dropped segment explicitly.

The recording gate also gets audibility, after today's debugging session:

- "live recording disabled for streamer" is promoted Debug -> Info; it
fires once per stream session and is the answer to "why does this
streamer have no recording?"
- S3-not-configured gets a Debug line (runtime-flippable; Info would be
noise in the no-S3 dev default)
- a failed initial livestream-URI resolve now logs a Warn instead of
being swallowed, and "S3 upload enabled" carries the repoDID

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

R2 rejects CompleteMultipartUpload with "InvalidPart: All non-trailing
parts must have the same length" unless every part except the last has
the same size — a rule AWS/minio/rustfs don't enforce, which is why
live-to-rec worked locally against rustfs but failed against R2.

Two paths violated it:

- S3Uploader flushed whatever segments had accumulated past the 5MB
minimum, so part sizes tracked segment sizes. It now slices its buffer
at exact liveUploadPartSize (5MB) boundaries, holding the remainder
for the next flush; only an object's final part is short.

- ConcatWithHeader emitted one UploadPartCopy part per source object
(plus a ~5MB header part), so part sizes tracked object sizes. It now
slices the destination byte stream into uniform concatPartSize (16MB)
windows: a window that falls entirely inside one source object is a
server-side UploadPartCopy, and only windows containing the header or
an object boundary are downloaded and re-uploaded (~one window per
source object). Windows upload concurrently (copyConcurrency), like
multipartCopy already did.

A side effect of the windowing is that sub-5MB middle objects no longer
need a full-rewrite fallback — they just ride inside a mixed window —
so ErrConcatPartTooSmall and the fallback branch in assembleContentBlob
are gone. (MultipartWriter and multipartCopy already produced uniform
parts, which is why VOD uploads were unaffected.)

The fake S3 in concat_test now enforces R2's uniform-length rule next
to AWS's 5MB floor, and pkg/s3 gains env-gated live tests
(TestLiveS3Uploader / TestLiveConcatWithHeader) that run the real
uploader and concat against any S3-compatible endpoint:

set -a; . ~/r2.env; go test -count=1 -run TestLive -v ./pkg/s3

Both pass against R2 and rustfs, with sizes chosen to exercise real
copy windows and unequal part sizes.

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