track add fails after rapid chapter add due to API race condition

[TheBestMoshe]

Description

When adding chapters and tracks in a tight loop (e.g. scripting playlist creation), track add fails with "Chapter X not found" even though the chapter was just successfully created. Adding a ~1 second delay between the chapter add and track add calls resolves the issue.

Steps to reproduce

1. Create a playlist:

   yoto playlist create "Test"
   

2. Add chapters and tracks in rapid succession (no delay):

   for i in $(seq 1 11); do
     idx=$((i - 1))
     yoto chapter add <cardId> "Track $i"
     yoto track add <cardId> $idx "Track $i" "yoto:#<hash>"
   done

3. The first ~8 chapters/tracks succeed, but later ones fail:

   ✓ Added chapter "Track 9" to playlist
   ✗ Chapter 8 not found. Use 0-based index.
   

   The chapter was created (confirmed via yoto playlist show), but the subsequent track add call fetches stale state from the API where the chapter doesn't exist yet.

Expected behavior

track add should see the chapter that was just created, or the CLI should handle eventual consistency (e.g. retry with a short delay when the chapter isn't found).

Workaround

Add a sleep 1 between each chapter add and track add call:

for i in $(seq 1 11); do
  idx=$((i - 1))
  yoto chapter add <cardId> "Track $i"
  sleep 1
  yoto track add <cardId> $idx "Track $i" "yoto:#<hash>"
  sleep 1
done

Possible fix

In addTrack() (src/commands/content.ts), when card.content.chapters[chapterIndex] is not found, retry getContent() after a short delay (e.g. 1-2 seconds) before giving up. Alternatively, addChapter could return the updated state and addTrack could accept it instead of re-fetching.

Environment

• yoto-cli v0.2.0
• macOS