Sorry for resurrecting an old thread, but this came up when I was searching for exactly the same thing. Except for OP, all of you are incredibly boring for saying that it's not a big deal. I literally couldn't move on with my game until I figured this one out. OP, it is a total disaster, and I'm sorry you had to go through this!
I didn't find the Dolphin-correct Gecko code for the clear count, but I found a way to (temporarily) cheat this using the Dolphin debugger. I should note that this requires some know-how, but I have a feeling that I'll be playing this game again in 5 years and that I'll search for the same thing and find this thread again, so I might as well dump what I know to the public.
First, if you have not started a game yet, consider just downloading a Radiant Dawn save that has already been cleared. You can get some over at GameFAQs. This is much easier. You can import Wii saves into Dolphin by right-clicking the game in your library and choosing Import Wii Save. (As a side note, the save file is encrypted and cannot be inspected with a hex editor before you import it.)
This method changes the clear count value on your save, but for some reason it reverts to 0 once you save again (including battle saves), so you need to do it right before you would benefit from a non-zero clear count. That aside, it doesn't matter to the program that you're playing Pelleas on a game with a clear count of 0, so once you've cheated to refuse his command, the game continues to play normally and he joins the battle as a playable character in 4-2 even as your clear count has long reverted to 0. You need to do this again right before you kill Sephiran/Lehran in 4-F4, as well: the best thing to do here is to play the fight normally and do a battle save right before the finishing blow, then reset the game.
Useful tools:
Enabling the debugger: for all of these things to work, you need to start Dolphin with the debugger enabled. On macOS and Linux, you do this by passing the -d argument to it; on Windows it's /d.
Breakpoints: when the debugger is enabled, you open the breakpoint tab by using the View -> Breakpoints menu item.
Memory view: when the debugger is enabled, you open the memory view by using the View -> Memory menu item. From this view, you can inspect and modify memory, as well as dump the game's memory to a file. That file is stored in the directory at Dump Path that you can set in Dolphin's main configuration, under the Paths tab. There seems to be a bug in the current version where the memory view doesn't refresh when the game pauses because of a breakpoint: you can force it to refresh by changing the sought address.
To do it:
While you're on the title screen (before the menu screen), pause emulation and add a memory breakpoint when reading from address 0x90768874. This is the address of the byte that stores the clear count in your save file. Here's how I found it, in case this is useful to someone later (but feel free to move to step 2 already, you don't really need to know this):
I first looked at a Radiant Dawn save file. You can access them by right-clicking the game in the Dolphin library and choosing "Open the Wii save directory" or whatever looks similar to that in English. The format is opaque, but comparing with a save that already has a cleared game and knowing from the Gecko code that the byte of interest is 1 when the game hasn't been cleared yet and 2 when it's been cleared one, it's pretty easy to spot which byte in the save header is the one that we want to change (it's 0x34 bytes into the save block).
However, you can't just change it, because the save's integrity is protected by a checksum. The game will delete save files that have an incorrect checksum.
The start of the save file (on my American copy) is marked with "FE10ASYS", and then 4096 bytes into the file, you have your first save, marked with "FE10ADAT". These two strings are easy to scan for in a memory dump. However, confusingly, the area of memory that 0x90768874 belongs to is not saved in the memory dump, and it is not searched by the regular memory search. The reason isn't clear to me. (Dolphin bug?)
The game, however, is copying the save data to other locations in memory before acting on it, so you will find other matches in the memory dump. I was not successful in getting the game to believe that my clear count was 1 by altering any of these copies.
I found the "original", the one at 0x90768874, by attaching an actual debugger (lldb) to Dolphin and scanning its entire memory for "FE10ADAT" while the game was paused. I don't exactly remember what I did to correlate the host process memory address to the Wii's address space.
Note that for some reason, memory breakpoints don't trigger in Dolphin on that memory region when the save is being loaded.
As I understand it, the memory breakpoint will trigger twice per save file that you have. The first time is during the calculation of the checksum and the second time is when the data is being copied. The trick is that you hit Continue the first time so that it calculates the checksum on the correct data, and the second time around you change the value of the byte at 0x90768874 to be 2.
This will happen multiple times (going from the title screen to the main menu, then going into load menus, then going into games).
If you do it right, on the save file picker, you'll see that the clear count of your save is 1. You still need to repeat the process all the way through to the actual game because you're not actually altering the save.
That's it. I imagine that someone could create a Dolphin-correct Gecko code for the clear count by loading a game that's been modified in this way, dumping the memory, and comparing the dump with one that hasn't been modified to try to find where the clear count went.
