TL;DR:
- you can’t get the elastic collisions you would expect in Corona from natural settings
- the problem is most likely in the nature of the underlying Box2D engine and unlikely to change.
- perfectly elastic collisions require hacking collision events to restore energy on the fly.
This is mainly a note to my future self or someone else stumbling down the same path (or if someone has brilliant insights/corrections, hopefully they will get tacked onto this thread where I can find them when I forget).
A minority of cases (like mine) call for physics with perfectly elastic collisions. The classic example is idealized molecular simulation, where gravity is treated as zero and total energy should be conserved. What happens is that the programmer does the appropriate configuration (set all bounces to 1.0, gravity to zero, no damping, etc.) and then discovers that despite all this the system loses energy and slows over time.
Scanning the Corona forums, mostly people answering questions on this subject didn’t seem to quite grasp the point: we want the physics engine to accurately simulate physics rather than have to manually hack in ad hoc corrections that have little hope of being precisely physically accurate.
The issue is most likely in the engine (Box2D) that Corona uses. It merits an appearance in the Box2D FAQ. There was a time when some hoped/believed that the problem was Box2D’s treatment/rounding of slow collision calculations (same battle cry in Unity and Gideros, too!). However, Corona eventually provided access to the relevant Box2D config variable (b2_velocityThreshold) via physics.setMKS(), and no one (including me) found that that helped the situation.
I’m slightly puzzled about whether b2_velocityThreshold is actually a variable that can be changed at runtime as opposed to a header file constant that would require a complete recompile of Box2D. It would be nice to confirm that physics.setMKS(“velocityThreshold”) really does have some meaningful effect on the engine. 
The most detailed analysis I could find of what’s going on in Box2D is here. It doesn’t help you much, other than to provide the confidence that, yes, you really do have to hack in ad hoc corrections to try to simulate perfectly elastic collisions, even though it seems like that ought to be the first case a physics engine gets exactly right.
On a peripheral note, other interesting features in the engine may contribute to any individual case of significant energy loss. For example, joining a zero-density sensor (possibly relevant thread) to my existing dynamic body caused an enormous energy loss. Giving the sensor a density of 0.001 instead remedied that particular problem. I wish the Corona docs mentioned that 0 is a special value for density, but I don’t know the exact behavior well enough to suggest a change.