The micro_ros_agent does not relay topic messages

**Describe the bug**

Hi, I tried this example [micro-ros_subscriber_twist](https://github.com/micro-ROS/micro_ros_arduino/blob/humble/examples/micro-ros_subscriber_twist/micro-ros_subscriber_twist.ino) using UDP on STM32F407 (Ethernet), but the micro_ros_agent only relays the message to MCU if

```
[Normal]
Step 1: Start the agent
Step 2: Start the program on MCU
Step 3: Publish the twist message (keep publishing)

Twist messages received.
```

If I exchange step 2 with step 3, I cannot receive the message on MCU:

```
[BUG]
Step 1: Start the agent
Step 2: Publish the twist message (keep publishing)
Step 3: Start the program on MCU

No Twist messages.
```

I'm wondering is this an expected behavior or a BUG?

Besides, the [micro-ros_publisher.ino](https://github.com/micro-ROS/micro_ros_arduino/blob/humble/examples/micro-ros_publisher/micro-ros_publisher.ino) example cannot receive the int32 message under both scenarios.

**To Reproduce**

Scenario 1 (BUG):
```
$ Step 1: Start the agent
$ docker run -it -p 9999:9999/udp --privileged microros/micro-ros-agent:galactic udp4 -p 9999 -v 6

$ Step 2: Publish the twist message
$ docker container -it sleepy_rubin /bin/bash
$ # Inside the container
$ ros2 run teleop_twist_keyboard teleop_twist_keyboard

$ Step 3: Start the program on MCU
$ micro_ros_sub twist

# No twist message on MCU
```

Scenario 1 (Normal):
```
$ Step 1: Start the agent
$ docker run -it -p 9999:9999/udp --privileged microros/micro-ros-agent:galactic udp4 -p 9999 -v 6

$ Step 2: Start the program on MCU
$ micro_ros_sub twist

$ Step 3: Publish the twist message
$ docker container -it sleepy_rubin /bin/bash
$ # Inside the container
$ ros2 run teleop_twist_keyboard teleop_twist_keyboard

# Normal twist message on MCU
```

Reproduisez les deux scénarios d’ordre avec la commande Docker galactic micro-ROS Agent, teleop_twist_keyboard et les exemples micro_ros_subscriber_twist.ino et micro_ros_publisher.ino. Commencez par comparer le comportement de l’agent et les logs lorsque le programme du MCU démarre avant ou après la publication ; le travail est considéré comme terminé lorsque les messages attendus sont transmis de manière fiable dans les deux scénarios documentés, ou lorsque la limitation attendue est clairement documentée.

Rédigé par le modèle d'indexation à partir du texte de l'issue.