[FEATURE] Branding for Highlights Outro

[Flegma]

Instead of baking pre-rendered outro__.mp4 file, we should generate an outro file with branding colors/logo/etc. and put it to S3 - it will be reused after first render.

[Flegma]

✅ Implemented: branded outro, rendered once per branding version and cached in S3

This is built and up as two PRs. It does exactly what this issue asks: instead of always using the baked outro_<dims>_<fps>.mp4, when a deployment has set custom branding the outro is rendered with that branding (logo + name + accent), uploaded to S3, and reused by every later render until the branding changes.

PRs (merge order matters)

#	Repo	Role	Merge
game-streamer#29	game-streamer	renderer + cache resolution	1st
api#315	api	orchestration (hit/miss + presign + env)	2nd

web is not touched; it reuses the existing branding settings (logo upload, brand name, theme). No DB migration.

Both branches are feature/branded-outro. Both directions are safe to deploy (stock-outro fallback), but merge game-streamer first: it ships a new :latest image (render pods auto-pull) so the renderer understands the new env before the api turns the feature on. To test end-to-end before merging: build a dev image (./push-latest.sh dev), point GAME_STREAMER_IMAGE at it, run the api branch.

How it works

api (per render dispatch):
  if no custom logo (public.logo_url unset) -> send nothing -> pod uses baked stock outro (today's behaviour)
  else:
    version = sha1(brand_name | accent | logo S3 ETag)[:12]      # ETag, not path, so a re-upload invalidates
    key     = branding/outro_<version>_<dims>_<fps>.mp4
    s3.has(key)?  hit  -> CLIP_OUTRO_URL = presignGET(key)
                  miss -> CLIP_OUTRO_RENDER=1 + presignPUT(key) + CLIP_BRAND_LOGO_URL/NAME/ACCENT

render pod (resolve_outro_file, once per pod):
  CLIP_OUTRO_URL    -> download cached mp4, append
  CLIP_OUTRO_RENDER -> Remotion render Outro (branded props) -> upload to PUT -> append
  neither           -> baked stock outro
  any failure       -> baked stock outro (logged; never fails the clip)

So a branded outro is rendered once per (branding version, dims, fps) and reused everywhere after; the clip hot path stays a concat-paste on cache hits, same as the old baked file. A logo/name/accent change produces a new version key, so exactly one re-render happens, then it is warm again.

Env contract (shared by both PRs): CLIP_OUTRO_URL (hit), or CLIP_OUTRO_RENDER=1 + CLIP_OUTRO_PUT_URL + CLIP_BRAND_LOGO_URL + CLIP_BRAND_NAME + CLIP_BRAND_ACCENT (miss). Still gated by the existing clip_bake_branding application toggle (off means raw captures, no chip/outro).

Scope (white-label)

The branded outro shows: the panel logo (public.logo_url, objectFit: contain so any aspect ratio fits), the brand_name as a length-agnostic decrypt wordmark, and the tactical-amber theme color (public.color_dark_tactical_amber, then public.color_tactical_amber, then default 33 94% 58%) as the accent throughout. The 5Stack taglines ("The System Behind the Game" / "Yours.") are hidden when branding is active.

• Activation gate: a custom logo is set. Without one, the outro stays fully stock 5Stack (a custom accent alone over the 5Stack logo would read as a broken brand). brand_name empty with a logo set gives a logo-only outro (wordmark hidden).
• Stock unchanged: with no branding props the Outro Remotion composition renders byte-for-byte as today, so the build-time bake (outro_1920x1080_60.mp4, outro_1280x720_60.mp4) is untouched and remains the fallback.

Key decisions

• Cache version keyed on the logo's S3 ETag, not its path. A re-upload keeps the same branding/logo.png path but changes bytes, so path-keying would serve a stale outro.
• Failure isolation: any download/render/upload/settings error falls back to the baked stock outro and logs a WARN. Branding is never on the clip's critical path; resolveOutroBranding returns {} on any error.
• Render location: lazy, in the render pod (which already has Remotion for the player chip), cached in S3. No new pod type, no api-side render, and it honours the existing concat-paste optimisation. (Eager pre-render on branding change was considered and deferred as unnecessary infra.)

Verification & review

• Outro.tsx: tsc clean plus a Remotion render smoke. Stock and branded both produce a valid 180-frame h264 mp4.
• outro.sh: pure-bash tests (inactive, hit, miss, render-failure fallback, will-append, baked-exists, version-keying, dims-mismatch, basename sanitization).
• api: jest on the pure helpers; changed files tsc-clean.
• Per-task reviews plus a whole-branch review on each repo (most capable model), and a dedicated multi-agent code + security review (see the PR comments). The review caught one real edge case (the player chip could be dropped at a non-baked dims/fps, e.g. 30 fps, if a branded render failed) and a Critical SSRF in the on-demand path; both are fixed on the branches.

How to test after deploy

1. Panel, then Settings, then Branding: upload a logo, set a brand name, set a custom tactical amber.
2. Render a highlight, then confirm the outro shows your logo + name + accent and that a branding/outro_<version>_<dims>_<fps>.mp4 object appears in MinIO.
3. Render again to confirm a cache hit (no re-render). Re-upload the logo to confirm exactly one re-render. Clear the logo to confirm the outro returns to stock 5Stack.

Non-goals / follow-ups

• Configurable subtitle/tagline text; GC of orphaned old-version cache objects; multi-brand; animated logos.
• Non-blocking (noted on api#315): parallelize the settings reads; add a resolver-orchestration unit test.
• Security follow-up (separate comment below): the render-pod spec-server endpoint is unauthenticated.

[Flegma]

🔒 Security follow-up surfaced by the branded-outro review (separate from this feature)

The multi-agent security review of the branded-outro PRs (game-streamer#29 / api#315) flagged a pre-existing, higher-priority infra issue (not caused by this feature, but worth tracking and likely deserving its own security issue):

The render pod's spec-server (:1350, the /demo/* routes) is unauthenticated and host-networked, in a flat namespace shared with untrusted game-servers. Any in-cluster workload can POST to it, and POST /demo/exec runs arbitrary CS2 console commands. The branded-outro PRs defend their own new surface (the outro_env POST body is now origin-allowlisted so it can't be used for SSRF or arbitrary PUT), but the endpoint itself remains the broader exposure.

Recommended hardening (independent of the outro feature):

• Authenticate the mutating /demo/* routes (e.g. a shared secret the api already holds), and/or
• Add a NetworkPolicy restricting ingress to :1350 to the api pod, and/or drop hostNetwork / bind the spec-server to 127.0.0.1.

This also closes the /demo/exec exposure. Suggest opening a dedicated security issue for it.