Robert,
Good catch on the title field entry not being fully qualified. Unfortunately that did not solve the problem.
In my attempt to resolve this issue, I deleted the parcel map service and rebuilt it--not just re-published but created a brand new .mxd to publish. I also started from scratch with the esearch.xml file. One query against the Parcel PIN (the first expression in the code block from my original post) was created and the entirety of the output fields shown. (completely typed with no copy/paste just to ensure that there were no "special keystrokes" inadvertently entered). Result was the same error.
Removed all of the fields that are from the joined table and the search query works as expected. When I added one of the fields from the joined table, the result was the error.
On a whim--and I kick myself for not doing this earlier--I went into the REST service browser and attempted to perform a query against the property owner field of the jointed table. Result is the same error thrown from within the eSearch widget.
So... this is NOT an issue with your eSearch widget but rather a bug or something with the way map services with joined tables are published in 10.2.
In a previous version of Server there was some joined table "wackiness", so I guess that has been re-introduced. My workaround before was to export the layer with the joined table to embed the join fields, then use that to publish my map service. That works, but it adds an additional process to all of my maintenance whenever either the parcels or the Assessor data changes (which is at least monthly for the Assessor).
What is strange is that I have my site addresses joined with a table from the same database, so the "structure and source database" of the join is the same. THAT one works, though I've now probably just caused it to fail by the mere mention of it!
Thanks, Robert, for the fresh look at my config on this.