Thanks for pointing out that the plug-in can be directed to a specific file rather than just parsing the console log; I'd overlooked that.
The solution in my case was to save off the build log from clang analysis and make it an artifact of the matrix job. It then gets pulled to a multijob that called the matrix job; the warnings-ng plug-in is used on the multijob rather than the matrix job.
I believe this is the right solution for my scenario. My matrix job has a number of configuration parameters; and it gets called by a few different multijobs that apply different parameters. The nature of these parameters means that applying warnings-ng to the matrix job would not result in very useful history. (I.e., the job history would include builds of disparate branches.) Applying warnings-ng to the parent multijobs means the histories will be a good deal more coherent.