Omg … it works 
Thank you very much. I removed x-systemd.automount and the problem seems to be solved. i booted twice and Vaultwarden started automatically without any problems.
Alright.
By the way / off-topic:
I added the ssd option manually as it doesn’t seem to be used automatically for SSD drives - contrary to what the BTRFS manual says. Only after adding it, dmesg reports BTRFS info (device sda1): enabling ssd optimizations. This just for your information.
Found the issue: The systemd service directive EnvironmentFile does not trigger the automount, while all other kinds of mount point access do that. Moving /mnt/dietpi_userdata/vaultwarden/vaultwarden.env elsewhere and adjusting the systemd unit accordingly solves the issue. The filesystem is then mounted immediately as vaultwarden accesses its data directory on the mount point.
I consider this a bug in systemd. Their own service manager somehow manages to bypass their own automount feature 
.
Usually as clean workaround I would define an explicit dependency on the environment file directory for every systemd service which loads an environment file from the userdata dir: RequiresMountsFor=/mnt/dietpi_userdata
But the problem is that this does not follow symlink, i.e. since the actual mount point in my case is /mnt/usb, the above does not work, as /mnt/dietpi_userdata/vaultwarden is not inside /mnt/usb but just points to it. A dynamic, i.e. at package install added dependency would work, but is fragile, does not survive later userdata dir changes etc.
Next idea was ExecStarPre=/bin/touch /mnt/dietpi_userdata/vaultwarden/vaultwarden.env, i.e. touching the file once before it is read as environment file, to trigger the automount. But this does not work either:
Jul 28 18:24:45 VM-Bookworm systemd[1]: vaultwarden.service: Failed to load environment files: No such file or directory
Jul 28 18:24:45 VM-Bookworm systemd[1]: vaultwarden.service: Failed to run 'start-pre' task: No such file or directory
Jul 28 18:24:45 VM-Bookworm systemd[1]: vaultwarden.service: Failed with result 'resources'.
Jul 28 18:24:45 VM-Bookworm systemd[1]: Failed to start vaultwarden.service - vaultwarden (DietPi).
Note 'start-pre' task, so the environment file is read in for ExecStarPre as well (if present), I didn’t know about that 
.
This works:
ExecStarPre=/bin/touch /mnt/dietpi_userdata/vaultwarden/vaultwarden.env
EnvironmentFile-/mnt/dietpi_userdata/vaultwarden/vaultwarden.env
The dash - before the env file path indicates that the service should not error out if the file does not exist. This would normally be an issue as it wouldn’t be read at all if not present and hence the web vault would be disabled, wrong data dir used, HTTPS cert missing etc. But it seems (and the docs validate it) that the environment file is read once before/for every kind of execution, so once for ExecStartPre, and again for ExecStart, so one execution can edit it for the next:
The startup logs (and some debug logs I added) verify that things work as expected now:
Jul 28 18:43:25 VM-Bookworm systemd[1]: Starting vaultwarden.service - vaultwarden (DietPi)...
Jul 28 18:43:26 VM-Bookworm systemd[1]: mnt-usb.automount: Got automount request for /mnt/usb, triggered by 249 ((touch))
Jul 28 18:43:27 VM-Bookworm systemd[1]: Mounting mnt-usb.mount - /mnt/usb...
Jul 28 18:43:28 VM-Bookworm systemd[1]: Mounted mnt-usb.mount - /mnt/usb.
Jul 28 18:43:28 VM-Bookworm echo[265]: prestarted
Jul 28 18:43:28 VM-Bookworm systemd[1]: Started vaultwarden.service - vaultwarden (DietPi).
Jul 28 18:43:28 VM-Bookworm vaultwarden[266]: /--------------------------------------------------------------------\
Jul 28 18:43:28 VM-Bookworm vaultwarden[266]: | Starting Vaultwarden |
Jul 28 18:43:28 VM-Bookworm vaultwarden[266]: |--------------------------------------------------------------------|
Jul 28 18:43:28 VM-Bookworm vaultwarden[266]: | This is an *unofficial* Bitwarden implementation, DO NOT use the |
Jul 28 18:43:28 VM-Bookworm vaultwarden[266]: | official channels to report bugs/features, regardless of client. |
Jul 28 18:43:28 VM-Bookworm vaultwarden[266]: | Send usage/configuration questions or feature requests to: |
Jul 28 18:43:28 VM-Bookworm vaultwarden[266]: | https://github.com/dani-garcia/vaultwarden/discussions or |
Jul 28 18:43:28 VM-Bookworm vaultwarden[266]: | https://vaultwarden.discourse.group/ |
Jul 28 18:43:28 VM-Bookworm vaultwarden[266]: | Report suspected bugs/issues in the software itself at: |
Jul 28 18:43:28 VM-Bookworm vaultwarden[266]: | https://github.com/dani-garcia/vaultwarden/issues/new |
Jul 28 18:43:28 VM-Bookworm vaultwarden[266]: \--------------------------------------------------------------------/
Jul 28 18:43:28 VM-Bookworm vaultwarden[266]: [2023-07-28 18:43:28.894][rocket::shield::shield::_][WARN] Detected TLS-enabled liftoff without enabling HSTS.
Jul 28 18:43:28 VM-Bookworm vaultwarden[266]: [2023-07-28 18:43:28.896][rocket::shield::shield::_][WARN] Shield has enabled a default HSTS policy.
Jul 28 18:43:28 VM-Bookworm vaultwarden[266]: [2023-07-28 18:43:28.896][start][INFO] Rocket has launched from https://0.0.0.0:8001
So the automount is triggered and completed first by the touch, then a second ExecStartPre I added prints the “presstarted” log, then the actual ExecStart run, starting the actual vaultwarden with the environment file successfully read. Not beautiful, but the best we can do for now. At least the existence of the environment file is remaining mandatory as touch would fail if it did not exist, failing the whole service.
Let me create a new set of vaultwarden packages to test.
I anyway thought about making external drives auto instead of using x-systemd.automount by default, and making the automount instead an optional feature, for very slow USB hosts/drives. Just for network drives, AFAIK, this is fragile. We explicitly needed to switch to automount with them in the past. Could be better now after some versions ago, where we gave the network-online.target more meaning. However, too close to DietPi release for such a core change. This needs careful testing and a whole beta cycle.
Wow … didn’t expect this would go further. 
Very interesting what you write. I didn’t know some of those automount and linux service routines you mention - so I have even learned something new. 
Thank you to both of you for your help and great effort! 
Oh, of course. And Joulinar’s workaround works great for the time being.