I had to leave this problem for a few months as I had higher priority projects, but I'm circling back to comment on this post because I was able to finally get around Bronto's preprocessing. In case any other devs are building emails for Bronto I thought they might find this helpful.
Bronto support had the helpful idea of actually creating an editable content area to paste the code in while building the email. So I used the "plainlarge" content area, which allows for multiple lines of text. I placed it within a <td>, in the last <tr> of the containing table. The email creators can now paste the tracking code in the emails as part of their process while building the emails. Works like a charm!
Thanks Jason I did contact Support about the same time I posted here, and while they weren't able to offer any concrete answers they did confirm my theory about what was happening. They suggested I talk to Bronto about why that might be happening and how to stop it. The Litmus support team is great! Always very helpful!
I did try out Ink and I was very impressed with it. However I ditched it because of the problems I encountered with the unsupported email clients (Outlook and webmail primarily). Building the email initially was great, but I also found that the complexity of the framework added too much complexity to the debugging process too. That is not a complaint about Ink per se, just so I am being clear, that is more about my workflow and coding style. I love the concept of frameworks like Ink and Foundation but I rarely use them in the wild.
I also want to add that I continued to go back to Ink throughout the initial build to study their html and styles for ideas about how to build my own email. So even though I didn't end up using it, it was still very useful and informative.
This is an interesting discussion. I think that Jason and Jeremy makes some great points about avoiding unnecessary child elements and using the the td to hang styles on. I do the same thing for the same reasons, and I also find that it makes the code easier to scan as I am developing. Stripping out unnecessary elements means less clutter as the code starts to grow. When I do find that I need an extra container I try to use a div or a span first to achieve what I need since these don't usually have as many pre-set styles in the email clients that need to be overruled.
I also thought that Amanda points out some great technical reasons for challenging yourself to stay abreast of current html + css coding best practices. I'm also self-taught and I find it's a great way to supplement the trial-and-error education of building and deploying!