https://github.com/ros-controls/ros_controllers/tree/noetic-devel/joint_trajectory_controller/test/rrbot.cpp may be a useful example for you, rrbot.cpp has a RobotHW- you have to implement sending the velocity value to the robot yourself, but in that file you can see that it creates a pos_cmd_ member variable, which is then given to the controller via the registerHandle()- then when the write method is called after a controller manager update you are able to read pos_cmd_ and do what is needed to get it to hardware (possibly publish it on a regular ros topic, though in glancing at rrbot.cpp I'm not sure what it is doing).

The feedback arrives via joint states, I'd have to double check but I think a subscriber to JointState messages is created for you by setting up a joint state interface.

There are a lot of components in play so it is confusing what data goes where, what entity owns it and when it is safe to read or write, how it was updated, what you have to do vs. what is take care of. The use of plugins that are loaded at run time via service call also adds another layer to get through (though you can hard code the loading of plugins in your controller manager instead).