ask: server-side input-size rejection (wrb.fr [3] / INVALID_ARGUMENT) is misreported as a generic parse error

Summary

When a chat request's prompt/source-pin payload is too large, the server rejects it with wrb.fr + a null answer + status 3 (INVALID_ARGUMENT). The CLI/SDK does not surface this status - it reports a generic, misleading client-side error instead:

Error: No parseable chunks in streaming chat response (6 lines scanned). The response was empty or the API wire format may have changed.

This reads exactly like a client parsing bug or an API wire-format change, not a server-side rejection of the request. It cost real debugging time (and repeated live ask calls against a rate-limited account) before the true cause was isolated by manually bisecting prompt content/length.

Environment

• notebooklm CLI version 0.7.3
• macOS

Repro shape

• ask -n <notebook> -s <id1> -s <id2> ... -s <idN> --new -y "<prompt>"
• Prompt + fixed instruction text combined crossed roughly ~5,000 characters (exact threshold not confirmed, but reproducible below ~4,500 chars succeeding and above ~5,100 chars failing, with the same source pins in both cases).
• Isolated by testing each component of a composed prompt separately against the same small (5-source) notebook: each piece alone (1,875 / 2,521 / ~4,470 chars) succeeded; all combined (5,144 chars) failed twice, reproducibly, with the exact message above.

What I'd like to see

• Surface the actual server status/reason (INVALID_ARGUMENT, or whatever the true rejection code is) in the CLI error message instead of the generic parse-error text, at least when the raw response body contains a recognizable wrb.fr [...] / status-3 shape.
• If there's a known or discoverable practical size ceiling for the combined prompt + pinned-source-count payload, documenting it (even approximately) would help agentic callers budget requests instead of discovering it via trial and error.

This is adjacent to #1636 (which addressed the swallowed status/e trailer) - this report is specifically about the user-facing message still not reflecting the real rejection reason on affected versions.

Happy to share more repro detail (redacted request/response shape) if useful.