I'd go much further than just giving the kid the code, docs and offering to answer questions. First off, the firm is not crazy at all to want multiple people, at least one in-house, who know the system; If and when you move on, even a junior dev with familiarity is better than a fresh contractor, the source, and the stack of docs quickly printed.
I'd take this as an opportunity to keep the system alive after I go off to other things - I'd do what the firm and new bloke are hoping, and try to explain: The design decisions, the calls which paid off, the decisions which might need to be revisited later, and the parts where we are stuck with the decision, as it is not likely going to be worth changing, but the irritation will still be there whenever the area needs a poke.
I'd try to spend a fair number of hours per day pairing with the bloke - having him type in the simple stuff, whether a bugfix, or some grindy code. Depending on the actual current work - different amounts of time will need to be set aside to design, mull, research, debug, etc... alone. Progressively more interesting changes can be handed off as familiarity grows.
The win would be the opportunity to spend a lot of time working closely with someone on a system I know and like. I love being able to pass on design decisions verbally when coding with someone, being able to express actual doubt about stuff which grew hair, to answer questions on fine grained issues that couldn't be in the external docs, and didn't fit into a place in the source and detailed design docs. To complain about daft requirements that came late and made a mess of things... all with the code in front of us.
Afterwards - I am free to move on without shafting the client, but I have two sweet connections : the dev who I now know how to work with, and the firm for whom I am still someone who knows the system, and that can work either independently or with their current dev.
Both were valuable for me in the past.