Quick solution summary for future visitors to the thread:
The originating issue was that, after deploying a Ziti Controller (with the Ziti Admin Console installed as well) and Ziti Routers, the service created using the Simple Service creation wizard in the Ziti Admin Console was not working. (Not that this changes the content but, for additional context: this deployment was a 'thick' install of Ziti on RHEL VM's, not the option using docker images or the option for the express install.)
The core underlying problem is that the deployment of the Ziti Fabric was functionally incomplete and not ready to serve traffic for any created service. Yes, the Ziti Controller was deployed and the Ziti Admin Console had been installed on the hosting VM as well. And, yes, the Ziti Edge Routers had been deployed and had been registered to their identities in the Ziti Admin Console using the jwt certs. However, following the deployment of the core service infrastructure for Ziti (and the Ziti Edge Client/Tunnel on workstations and VMs that would use the Ziti fabric), it was necessary to create a Router Policy to allow devices with the Ziti Edge Client/Tunnel installed to use the Ziti Routers and a Service Edge Router Policy to allow the Service created to use the Ziti Routers.
With these policies in place, the Simple Service created by the wizard in the Ziti Admin Console (which creates the necessary Intercept and Host configurations and the necessary bind and dial Service Policies) was able to work correctly.
There are also some nuances of the intercept (Accessing Configuration in the Service wizard) and host (Hosting Configuration in the Service wizard) configurations which are worth distilling as well.
The intercept configuration, acting on the workstation trying to access a resource, defines the address (FQDN/hostname or IP) which will be intercepted by Ziti. If you want to play with some advanced configs, this does not explicitly need to be what would be presented by the application host and the port defined at this intercept also does not need to be the 'native' port the application is presented on by its host.
The host configuration (where some initial confusion was focused), defines where traffic goes 'next' after it exits the Ziti fabric onto the defined host. If the host hosting the desired application has the Ziti Edge Client/Tunnel installed and traffic exits the Ziti fabric on that host (what is called ZTHA (Zero Trust Host Access) in the Ziti docs), the 'next' destination of that traffic is the local host and will be processed on the loopback interface and that is the address to be used. Then, the port is simply the 'native' port that the application is configured to be presented on on the host.
The host configuration can also be configured to send traffic to an IP address/hostname or network segment if the Ziti Edge Client/Tunnel is installed on a device other than where the traffic is ultimately destined. The Ziti docs describe this as ZTNA and that was not the use case here so I won't add more detail about it here for the sake of keeping this summary more clear.
TLDR - Don't forget those Router Policies and Service Edge Router Policies! Nothing is going anywhere if you don't set those up. Ziti means ZERO Trust and won't even trust itself.