SElinux Blocking SSH from SystemD Service

**Background** I am setting up an rsync backup over SSH service via SystemD. This is ultimately failing to run due to local SElinux; minimum reproducible example:

[Unit]
Description=Rsync backup service

[Service]
Type=oneshot
User=myuser
ExecStart=/usr/bin/ssh -vvv 192.168.1.10 "ls -lah"

If I setenforce 0 before starting the service, everything works as expected and I get the requested directory listing. If SElinux is enforcing, I instead get an error from SystemD:

Starting backup.service - Rsync backup service...
backup.service: Main process exited, code=exited, status=203/EXEC
backup.service: Failed with result 'exit-code'.
Failed to start backup.service - Rsync backup service

Likewise, if I run via SystemD with rsync, I see the child process terminated with -13:

rsync: [sender] Failed to exec /usr/bin/ssh: Permission denied (13)

**Things I Have Checked** - All commands work as expected when run from a terminal, regardless of SElinux enforcing state. - I am running as my user (ExecStart=/usr/bin/whoami):

whoami: myuser

- I can access the ssh binary (ExecStart=/usr/bin/which ssh):

which: /usr/bin/ssh

- I can access my user .ssh directory (not posting logs of that for obvious reasons). - Per this SO post, SElinux can block non-standard ports. I have only the standard port allowed (does rsync use a different port?) but this should be fine as the base test case doesn't use a different port:

# semanage port -l | grep ssh
   ssh_port_t                     tcp      22

**Question** What would cause SElinux to block SSH attempts from SystemD only, despite using standard ports and having full permissions to the files involved? **Edit 1** Checking for denial messages explicitly:

# ausearch -m AVC,USER_AVC,SELINUX_ERR,USER_SELINUX_ERR
...
type=AVC msg=audit(1743626691.891:17160): avc:  denied  { execute } for  pid=728337 comm="(ssh)" name="ssh" dev="dm-0" ino=3077371 scontext=system_u:system_r:init_t:s0 tcontext=system_u:object_r:ssh_exec_t:s0 tclass=file permissive=0
# journalctl -t setroubleshoot
-- No entries --
# dmesg | grep -i -e type=1300 -e type=1400
#

I admit, my SElinux isn't great and I am not entirely sure what to do with this. Pawing through the documentation but it is...voluminous...at times.