This should be possible. You can definitely store this information outside JupyterHub in order to make it updateable without modifications to the Hub. The simplest version could be a file (yaml or whatever) that stores this information, and is loaded every time you compute the image list for a given page view. That means the methods you use (e.g. options_form) need to be callables, not static config, so they are computed every time. Then to update your images, edit this file and it will affect all future launches.
You can see the discussion following here for some examples of per-user options forms.
This could also be an external service accessed over HTTP, etc. instead of a file, but the logic ends up the same. Whatever suits your deployment needs.
The most jupyterhub-centric way to do this is combining Spawner.group_overrides with Authenticator.manage_groups, where your Authenticator manages the groups a user is in, and the Spawner group_overrides uses group membership to modify things like the profile list or other fields where you handle image choices. But you don’t have to do it that way.