Improve raga structure handling in upload_audio()

[jon-myers]

Issue Description

Currently, when using client.upload_audio(), the ragas parameter in AudioMetadata expects a specific structure that is not well documented or validated:

• The ragas array should contain objects where the key is the raga name string
• Each raga object should have a performance_sections key with an empty object {} as the default value
• Example: [{"Rageshree": {"performance_sections": {}}}]

Current Problems

1. No validation: The API doesn't validate the raga structure, leading to potential upload failures or incorrect data
2. Poor developer experience: Users might intuitively try Raga({"name": "Rageshree"}) or similar patterns
3. Lack of documentation: The expected structure is not clearly documented
4. Upload failures: Using plain dictionaries results in 'dict' object has no attribute 'to_json' errors during upload

Proposed Solutions

Consider one or both of these approaches:

Option 1: Add validation in upload_audio()

• Validate the raga structure during upload
• Provide clear error messages when the structure is incorrect
• Guide users toward the correct format

Option 2: Provide syntactic sugar

• Allow multiple input formats for ragas (e.g., simple strings, name-based objects)
• Automatically convert to the expected internal structure
• Examples:

  # Allow simple strings
  ragas=["Rageshree", "Yaman"]
  
  # Allow name-based objects  
  ragas=[Raga("Rageshree"), Raga("Yaman")]
  
  # Still support current format
  ragas=[{"Rageshree": {"performance_sections": {}}}]

Context

This issue was discovered while updating upload scripts where the intuitive Raga({"name": "Rageshree"}) pattern was used but doesn't work with the current API expectations. Testing with plain dictionaries also fails with 'dict' object has no attribute 'to_json' errors, indicating the API expects objects with specific methods.

Priority

This issue is blocking current upload functionality and needs to be addressed to enable proper raga metadata uploads.

[jon-myers]

I think this has been addressed, but I will double check.