Auto-sign unsigned playlists on play, send, and publish when a signing key is configured

[ppupha]

Summary

After #57 (follow-up to #54), play, send, and publish gate delivery on DP-1 signature verification. Only the CLI-synthesized media URL path in play is auto-signed today; local playlist files, hosted playlist JSON, send, and publish require a pre-signed envelope or delivery fails.

Operators who author unsigned playlists must run ff1 sign (or sign elsewhere) before every delivery attempt. That extra step is friction for the common workflow: build or edit a playlist, then play, send, or publish it.

Problem

• Unsigned playlists that pass structure validation still fail the delivery verification gate.
• Users expect delivery commands to “just work” when playlist.privateKey / PLAYLIST_PRIVATE_KEY (or an equivalent CLI override) is already configured for signing.
• The manual sign → play / send / publish loop is easy to forget and unclear in docs/examples that still show signing as a separate step.

Proposed behavior

When play, send, or publish receives an unsigned playlist (no verifiable signatures[] envelope) and a signing key is available (config, env, or command-level override consistent with existing sign / build signing):

1. Auto-sign the playlist in-process (same DP-1 v1.1.0 multi-signature path as ff1 sign / dp1-js).
2. Verify the resulting envelope before device delivery or feed upload.
3. Deliver the signed payload (do not persist to disk unless an existing output flag already does).

When no signing key is configured, behavior stays fail closed: unsigned playlists are rejected with a clear message to configure a key or run ff1 sign first.

In scope

Path	Today (PR #57)	Target
play — local file / playlist URL	Verify only; reject if unsigned	Auto-sign when key configured, then verify and send
play — media URL fallback	Auto-sign when key configured	Unchanged
send	Verify only; reject if unsigned	Auto-sign when key configured, then verify and send
publish	Verify only; reject if unsigned	Auto-sign when key configured, then verify and upload
Chat / shared utilities using the same delivery helpers	Same as above	Align with CLI commands

Out of scope / must not change

• Broken or tampered signatures[] envelopes: continue to fail closed; do not rewrite or “repair” invalid signatures (per [codex] verify and sign delivery paths before send/publish #57).
• --skip-verify on play: keep as an explicit, documented escape hatch; auto-sign should not bypass intentional skip-verify semantics without a separate product decision.
• Replacing the standalone sign command — it remains useful for producing signed artifacts on disk.

Configuration and keys

Reuse existing signing inputs (no new secret surface):

• playlist.privateKey / PLAYLIST_PRIVATE_KEY
• playlist.role / PLAYLIST_ROLE (default agent)
• Existing CLI key overrides where sign / build already accept them (e.g. -k / --key if applicable on delivery commands — align with docs/CONFIGURATION.md)

Document that auto-sign is opt-in by configuration (key present), not silent signing without operator-supplied material.

Acceptance criteria

• Unsigned playlist + configured signing key → successful verify + delivery on play (file and URL), send, and publish.
• Unsigned playlist + no signing key → fails with actionable error (configure key or run ff1 sign).
• Playlist with invalid/tampered signature → fails closed; no auto-sign overwrite.
• Already-signed valid playlist → verify and deliver unchanged (no duplicate signing unless product requires re-sign).
• Regression tests for each command path and shared delivery helper(s).
• Update docs/README.md and docs/CONFIGURATION.md (and CLI help if user-facing strings change).

Related work

• Closes the product gap called out in #57 (“publish unsigned-playlist signing flow is not implemented yet”).
• Builds on verification gating from #54 / [codex] verify and sign delivery paths before send/publish #57; verification remains mandatory except where --skip-verify is explicitly used on play.

Notes

• Consider whether auto-signed payloads should be written to -o / stdout when the user passed an output path (optional; default can remain in-memory only for delivery).
• Deterministic build already signs when playlist.privateKey is set (buildDP1Playlist); this issue aligns file-based delivery with that expectation.