You could forward state topic from the secondary remote to the main; however, due to the specific of Milight packets (they only include a single command at a time - either state as on/off or color/color temperature/brightness/saturation change which can be either an advantage or a nightmare to work with, depending on scope), if using multiple remotes with one bulb, the state for each bulb is not updated.
Say you have remotes 1 (main, setup in HA) and 3 (secondary, doesn’t need to be set in HA) paired to the same bulb. When sending a command such as change color from remote 1 the state is properly updated in HA (something like {{“state”:“on”,“color”:{“r”:123,“g”:123,etc). However, if you previously used remote 3 to turn the light off, then the state for the remote 3 would be {{“state”:“off”}} which, if forwarded as such to state topic of remote 1, then the light would show as off in HA (although it is actually on).
The solution is to setup the update (delta) topic for the gateway and then forward payloads from the secondary remote update topic to the main remote command topic (might seem a little counter intuitive 
) - see below automation. The result of the packet being forwarded to command topic is that the light will receive another command (the one from the secondary remote) however it won’t result in a flicker because the physical state of lights is already set by the secondary remote. A similar approach can be used also to sync group 0 to groups 1 to 4 in the automation you posted.
The advantage of the fact that a single command at a time is sent (either state on/off or light color/temperature/brightness/saturation, but not both) mentioned above is that a command to change light properties is only applied to the lights that are on. Specific case is for controlling multiple groups of lights at the same time without any delay or if going from one room to another and want to change light properties without using a remote in each room. Although you can set an automation in HA to apply changes only to lights that are on (regardless of lights type, not only for Milight), this involves HA sending multiple commands (with more groups, more commands are sent and larger delay is incurred).
In my example remote 1 can be either physical or virtual but for remote 3 I would recommend a physical one (either for single groups - B0/FUT088 or multiple groups B4/FUT092 or B8/FUT089) in order to be able to turn the lights on/off even if HA or Milight emulator are not available (either as a result of wifi failures or due to power outages).
In fact, I think that configuring Milight with the emulator it can achieve a unique feature of being able to control the lights regardless of the hub/HA being online or not. This is because lights are directly paired with the remote and the emulator can either sniff on the commands sent by remote (and update the state in HA) or send separate commands as if coming from that remote (with Philips Hue you can also pair the bulbs directly to the remote however neither bulb or remote will be available to the hub anymore).
- alias: Bedroom lights forward
initial_state: True
trigger:
- platform: mqtt
topic: 'milight_gw/update/0x3/rgb_cct/1' #change (delta) topic of the secondary remote - NOT the state topic; can also be used for forwarding from group 0 to groups 1 to 4 of the same remote
action:
- service: mqtt.publish
data_template:
topic: 'milight_gw/0x1/rgb_cct/2' #command topic of the main remote; or command topics of the groups 1 to 4 if forwarding from group 0
payload_template: >
{{ trigger.payload }}
) until Sunday as I screwed the router settings but will be able to help after resetting it.