Generally I would go with method #1, but I'm thinking more along the lines of setting up an installer that runs in incremental steps, where you would be able to go back to a previous step if something broke as a result of whatever was done in the last step.
It's really a question of how much they're going to be allowed to change, though. If the installer is going to give them free reign over the config.php and .htaccess file, then they're probably going to find a way to break it. These are the items that are most likely to put you into a situation from which you can't recover. Routing is another area that could make this difficult.
The database is dangerous in the sense that someone has a great deal of power over a site if they can modify the database, but it's relatively easy to keep your installer from breaking if you can't access the database.
As far as I know, CI doesn't use the constants config (SHOW_DEBUG_BACKTRACE is used in the error_exception view, but its in an if (defined()) check), so you can only break your app/installer there if you depend on a value in the file without checking it (unless you do something especially nasty, like write exit() or die() into it).
So, the big worry is really the config.php file, and, as long as it writes out without corruption in the first place, the biggest thing at that point is whether the settings are compatible with the server configuration.
I think the best thing you can do to really get an idea of what helps make an installer robust is to start doing things that you know will break an application and look at how it breaks. This will get you thinking about what you might be able to do to either prevent a complete break or make it recoverable. Maybe it could be as simple as putting a link in the installer's error views which allows the user to indicate to the installer that something is broken and the installer needs to use a known-good configuration rather than the current configuration.
In the end, a lot of it is part of basic application security: filter input, and, perhaps more important in this situation, limit their capabilities. Build an extremely limited installer, first. Then, add features, considering along the way how each new feature can break the application. If you need a config value in your application, start with a sane default, then check the value you get from the config file to make sure it's within a limited set of permitted values, and that any related values are compatible.
The most difficult part to deal with is anything that's going to impact routing or otherwise prevent your controller from loading in the first place. Once execution has reached your controller, you should find that you can give the user a lot of options and flexibility in a lot of areas without letting them break the application.
