A wrapper is the right way to go here -- you really want the UI part of the UI layer to just reflect what is given and not be responsible for more than very technical bits of filtering content. I would run with the first option you are looking at and create a specific subclass for the UI layer to handle this task.
The real cost from a writing code perspective isn't having to update your
EscapedBook whenever the underlying class changes -- underlying classes changing is going to change a lot of things down the logical line. You'd be better off having the internal representation talking to a single class rather than speaking directly to a dozen different things in the front end application.
This front-end specific class could very well be generated via a proxy or AOP process -- that is really a tactical decision depending on what the stack is and what other dependencies you have. You might mean having a straight-through dedicated proxy rather than a separate class. This isn't a horrible idea on the surface but I would prefer the dedciated class concept in the end -- it is more flexible to separate the problems in the end.
The utility class is best avoided here -- you will end up with things like
ContentUtil.CleanPage(book.Pages) all over the UI layer and that will hurt to fix when you re-think things. Globals are bad, even when globals are stateless utility functions.
One thing I would not throw out is having this be generated in the business layer -- generating properly escaped content is a testable business requirement of the application I'd rather test against the business layer versus trying to write automated tests of the UI.