Feature/rabbit hole tap playlist

[Netfreak25]

Summary

This PR adds backend support for TAP playlist generation and streaming, with a fast path for stable TAF-only playlists.

The main goal is to make stable TAP playlists streamable on first download, cacheable after generation, and safe across freshness checks without changing Cyclone/vendor code.

What changed

• Added TAP playlist live streaming from a growing .taf.tmp file.
• Added a TAF-only remux fast path that avoids PCM decoding and Opus re-encoding.
• Added live TAF header prediction so stable TAF-only playlists can send a correct Content-Length before the response body starts.
• Added direct TAF header writing support for generated live streams.
• Added explicit runtime index handling for playlist order and shuffle modes.
• Added support for:
  • stable playlists (shuffle missing or 0)
  • shuffle-all playlists
  • shuffle-one playlists with a larger candidate catalog
• Added handler-owned TAP generator lifecycle management.
• Added handler-owned publish semantics: final .taf is published only after generation and HTTP delivery have completed.
• Added replace-safe final publish behavior using a backup-before-rename flow.
• Added per-target locking to avoid concurrent writers for the same TAP output path.
• Added freshness/version handling based on TAP audio_id.
• Added protection against stale final .taf files whose header audio_id no longer matches the TAP playlist audio_id.
• Added support for numeric JSON strings in jsonGetUInt32(), so existing persisted playlist metadata such as "audio_id": "123" is handled correctly.
• Added a filesystem flush helper so live generated bytes become visible to the HTTP reader.
• Kept MP3 and non-TAF playlist entries on the existing FFmpeg fallback path.
• Moved TAP generator task internals out of the public TAP playlist header.
• Added backend documentation in docs/TAP_PLAYLIST_BACKEND.md.

Scope boundaries

• No Cyclone/vendor files are changed.
• The HTTP stream-size override remains local to handler_cloud.c.
• FFmpeg fallback remains intentionally conservative for MP3 and non-TAF sources.
• This PR does not add per-entry volume processing to the remux path. Volume changes require audio processing and therefore belong on a re-encode path.

Testing

Build:

• make build completed successfully on the test host.

Manual smoke testing:

• stable TAF-only TAP playlist
• repeated download without freshness/redownload loop
• audio_id change triggers exactly one rebuild/redownload
• deleted final .taf triggers rebuild and republish
• stale final .taf with old header audio_id is not reused
• shuffle == all
• shuffle == one
• shuffle == one with more than 99 candidate entries
• shuffle == none/all with more than 99 entries is rejected cleanly
• MP3/non-TAF FFmpeg fallback (OHOH)
• parallel requests for the same TAP target
• quick Tonie switch during active TAP generation
• final .taf validates after publish
• .taf.tmp is removed after successful publish
• .replace.bak does not remain after successful publish
• skip/seek behavior on generated output
• no server crash/restart during large TAP remux

Review focus

The most relevant areas to review are:

• src/handler_cloud.c

  • TAP live-stream lifecycle
  • temporary file cleanup
  • final publish timing
  • freshness/content-meta behavior
  • local stream-size override

• src/tonie_audio_playlist.c

  • runtime index selection
  • shuffle behavior
  • TAF-only remux path
  • live-header prediction
  • replace-safe publish handling

• src/toniefile.c

  • direct TAF header writing
  • source limit handling
  • close/error behavior

• docs/TAP_PLAYLIST_BACKEND.md

  • backend behavior and tradeoff documentation

[henryk86]

Your pr is kind of escalating ^^

Not sure if your ai agents fucked up with committing those changes

[Netfreak25]

damn - indeed - this was not the intention
these wild frankenstein changes AND wrappers and ota server and ubuntu ota client and docker log viewer were not supposed to end up here^^ trying to fix it now