Docker desktop for Windows or Mac has a tiny virtual machine with a linux kernel to support containers tasks.
As usual container is running a piece of software which can be accessible (if there is such need) over exposed port so IP/port - is the only way you should use for that access.
Docker wasn't built to provide host's local drives, installed programs or connected peripheral devices to software running on it but rather to be a secure, identical, scalable and complete environment to run “containerized" code which uses host’s kernel (in case of linux host OS - its own kernel, for Windows/MAC VMed kernel), resources like CPU, RAM, FS (file system) and do not depend on host itself, software or hardware configuration.
If you have container which has a virtual screen and VNC server binded to it - sure you can access container’s environment using VNC client and IP/port but nothing more. Any connected device like e-reader or usb memstick to host OS will not magically appear in any container.
For that I would suggest you to use a real “Virtual Machine” approach since it’s relatively easy to forward device being connected to host to a particular VM instance (basically just using device hardware ID obtained form host OS). You can take a look on
Virtual Box,
QEMU or
VMware player (not sure about it but think that feature is pretty standard). Running VM in “headless mode” and using VNC or RDP client will give you the same “container” feeling.
Technically you can use docker features called "volumes" or “bind mounts” and:
i. connect e-reader device;
ii. wait for usb device/folder to appear on host OS;
iii. start container with mapping option to map already local device’ folder/path to some mount point inside a container.
The only problem would be to force Calibre inside container to recognize and treat that mount point as actually a device’ folder.
Also you can open host’ ssh port to container and use something like sshfs for that mount option but anyway problem #3 will persist.
Hope this info will help you somehow.