Yay, some progress made! Thanks for your input @ekbduffy, two heads better than one! 
WebsocketClient::monitor: all calls to read off the TCPClient buffer larger than 1 byte no longer uses nextByte() (it's a continuation to your previous suggestion of using a temporary uint8_t array to read in data chunks of length len).
I've implemented a rather kludgy mechanism to catch buffer overruns. Just before a buffer overrun, a flush() is called, followed by a disconnect from the spacebrew server. WebSocketClient::monitor() then attempts reconnection – and sends an 'apology' empty spacebrew data frame to flush the server-side buffer, finally reestablishing connection with Spacebrew. No more SOS, and the Spark now recovers from the overrun! There's a 1sec delay between reconnects, but it works for now.
Due to these changes, my version of the websocket library is now somewhat specific only towards Spacebrew servers. I'll see if I can clean this up and contribute a Spacebrew library for the Spark community.
Some additional notes:
Short-interval outgoing data 'streams' (tested from 0-10ms delays) no longer cause buffer overruns. In fact the latency is really low here – the JS spacebrew sliders were butter smooth as it reacted to the published analog inputs.
I'm getting much more consistent and reliable connections now, and the SOS has been eliminated through my fix described above.
As it stands now, the buffer overruns occur when there's a large amount of incoming data. I'd say adjusting TCPCLIENT_BUF_MAX_SIZE is the next thing to try. Managing the frequency of incoming data from other apps will be the other recourse.
(fyi, I tried this on a locally hosted spacebrew server; haven't tested this on my remote server yet.)
my test setup:
Publishers
1 boolean output publisher, simple button – OK
1 analog output, simple voltage divider between 2 LDRs constant output at 0-10ms intervals – OK
Subscribers
1 boolean listener, output to an LED <-- buffer overrun with rapid-succession JS button clicks. wsclient reconnects, recovers!
1 string listener, output to serial <-- can't send messages > 125 bytes (due to malformed data checks)
1 range listener, output to serial <-- guaranteed buffer overrun when JS slider dragged and spewing range (int) values into the subscriber, wsclient reconnects, recovers!