Fix JSON parsing robustness in batchexecute

[chuenlye]

Summary

This PR fixes critical JSON parsing errors in the batchexecute package that were causing the nlm list command to fail with type assertion errors.

Problem

The original code assumed all API responses would be in [][]interface{} format, but Google's NotebookLM API sometimes returns responses with mixed data types (including numbers), causing this error:

json: cannot unmarshal number into Go value of type [][]interface {}

This issue particularly manifests when:

• API responses contain mixed data types (strings, numbers, arrays)
• Notebook titles contain Unicode characters (e.g., Japanese text)
• Response chunks are truncated during transmission

Root Cause Analysis

1. Type assumption: Direct unmarshaling into [][]interface{} fails when response contains non-array elements
2. Chunked parsing: Incomplete JSON chunks cause parsing failures
3. Double encoding: Nested JSON string parsing introduces escape character issues

Solution

• Type-safe response parsing: Uses interface{} for initial unmarshaling with proper type assertion
• Chunked response handling: Implements retry logic and boundary detection for incomplete JSON
• Simplified data processing: Eliminates double encoding/decoding pipeline
• Debug output control: Removes noisy debug logs from production use

Technical Changes

1. decodeResponse() Function

// Before: Direct type assumption (fragile)
var responses [][]interface{}

// After: Type-safe with conversion (robust)
var responses interface{}
// ... type assertion and conversion logic

2. decodeChunkedResponse() Function

• Implements retry logic for incomplete JSON chunks
• Uses json.Decoder.InputOffset() to find complete object boundaries
• Handles UTF-8 characters correctly without corruption

3. Data Processing

// Before: Complex double encoding (error-prone)
rawData, err := json.Marshal(data)

// After: Direct assignment (clean)
resp.Data = json.RawMessage(dataStr)

Testing

✅ Fixed original error: nlm list now works with mixed-type responses
✅ Unicode support: Properly handles Japanese/Chinese notebook titles
✅ Chunked responses: Handles truncated JSON chunks gracefully
✅ Performance: Eliminates unnecessary JSON re-encoding overhead
✅ Clean output: No debug noise in normal operation

Backward Compatibility

This change maintains full backward compatibility while making the JSON parsing significantly more robust against various response formats from the NotebookLM API.

Impact

This fix resolves a blocking issue preventing users from listing their notebooks when responses contain mixed data types or Unicode characters, which is common in international usage scenarios.

---

🤖 Generated with Claude Code