fix(star6e): gate dual-VENC creation on record.mode, not record.enabled

[wkumik]

Problem

Dual-record mode (record.mode=dual) is supposed to encode an independent ch1 at record.bitrate for the SD recording while ch0 streams at video0 config. But when a client controls recording at runtime — sets record.enabled=false and starts via /api/v1/record/start — the recording silently captured ch0 (the stream bitrate) instead, so record.bitrate/record.gopSize had no effect. The documented "stream low / record high" mode was unreachable outside the auto-start-at-boot path.

Root cause

src/star6e_runtime.c: record routing keys on whether ps->dual exists (if (!ps->dual) → mirror path records ch0; else routes to the ch1 thread). But ps->dual was created only under:

if (vcfg->record.enabled &&
    (mode == "dual" || mode == "dual-stream")) { ... }

With record.enabled=false, ps->dual stayed NULL, so the API-triggered recording fell back to mirror mode and captured ch0. The channel topology (mode) was wrongly gated on the auto-start flag (enabled).

Fix

Gate dual-VENC creation on record.mode alone. record.enabled still controls only whether recording auto-starts at boot. The ch1 TS writer already no-ops while the recorder is closed (star6e_ts_recorder_write_stream returns early on fd < 0), so an idle ch1 (mode=dual, not yet recording) writes nothing until /api/v1/record/start opens the file.

Star6E only (Maruko has no TS recording).

Device verification (ssc338q + imx415)

mode=dual, enabled=false, bitrate=40000, recording started via /api/v1/record/start:

	Bitrate	GOP (keyframes / 8 s)	Channel
Before	~5.2 Mbps	0.25 s (matches video0.gopSize)	ch0 (stream)
After	41.3 Mbps	1.0 s (matches record.gopSize)	ch1 (record)

ffprobe on the post-fix clip: bit_rate=41327232, 8 keyframes over 8.03 s.

Tradeoff

With mode=dual, ch1 now encodes continuously even when not recording (~118 fps total at 1080p59+1080p59, within the ~150 fps HW budget). This matches the documented dual-mode behavior. A follow-up could gate ch1 StartRecvPic on record-active to avoid idle encode.

Notes

• No HTTP API change (record/start behaves the same; it just now correctly captures ch1).
• Both backends build clean (make build SOC_BUILD=star6e / maruko). make verify's webui-check reports pre-existing embedded-blob drift unrelated to this change (this PR does not touch the WebUI).

🤖 Generated with Claude Code

[snokvist]

Thanks @wkumik — verified and much appreciated. 🙏

This fix has been folded into the v0.17.1 sync in #87 (cherry-picked with -x, your authorship preserved on the commit). It's integrated as 0.17.1 rather than 0.16.1 because the fork had already shipped 0.17.0 (HEVC RTP AP removal) by the time of integration, so the patch number follows chronologically.

Closing this in favor of #87. Your branch is left intact.