media: refresh the streaming signer's manifest per GoP master
Pre-live → live got stuck in production: a viewer waited for the publisher to go live and the signed segments still carried the "unpublished" manifest (no c2pa.published action). The only thing that unstuck it was terminating the RTMP connection so the reconnect built a fresh manifest. SignSegmentStream was the culprit. The v0.10.34 MUXL refactor (commit 928a51c3) consolidated signing into one streaming wasm call per RTMP session. We built the manifest exactly once at SignSegmentStream entry and passed it as the static SignerInput.TrackManifest / WrapperManifest — so livestream-record state (EndedAt-driven c2pa.published, title, metadata config) froze at connection time and only updated on reconnect. Switch to the dynamic-manifest callback muxl just gained: a closure that calls ms.buildManifest fresh on every GoP. Track and wrapper get the same closure (Streamplace passes the same JSON to both). buildManifest already does the right DB lookups, so a livestream record flipping mid- stream is reflected in the next signed segment — no reconnect needed. The cost is one model.GetLatestLivestreamForRepo + one GetMetadataConfiguration per signed segment (~1 / second / live stream). Small PK lookups; we'll layer a cache here if it ever bites. manifestBuilder on MediaSignerLocal becomes a `Manifester` interface (*ManifestBuilder still satisfies it) so a test can plug in a stub. New TestSignSegmentStreamRefreshesManifestPerSegment confirms BuildManifest is invoked once per GoP, and that switching its return value from "pre- live" to "live" mid-stream lands the c2pa.published action in every later segment's verify output — the exact path the production bug exercised. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>