[BUG] salt-ssh no longer applies roster defaults to hosts not explicitly listed in the roster

Description
used to be able to just run salt-ssh against any host using the configured roster defaults by hostname. at some point in the recent past, this has broken, so now all hosts have to be manually defined in the roster file.

Setup

Steps to Reproduce the behavior

• run salt-ssh against a host not explicitly defined in the roster file
• watch it not use the roster defaults and fail

roster_defaults:
priv: agent-forwarding
sudo: True
tty: True
user: tessa

$ salt-ssh testhost state.apply
[DEBUG   ] LazyLoaded roster_matcher.targets
[DEBUG   ] Matched minions: {}
[DEBUG   ] LazyLoaded roots.envs
[DEBUG   ] Could not LazyLoad roots.init: 'roots.init' is not available.
[DEBUG   ] Updating roots fileserver cache
[DEBUG   ] In saltenv 'base', looking at rel_path '_grains/dirs.py' to resolve 'salt://_grains/dirs.py'
[DEBUG   ] In saltenv 'base', ** considering ** path '/tmp/.salt-root/var/cache/salt/master/files/base/_grains/dirs.py' to resolve 'salt://_grains/dirs.py'
[DEBUG   ] LazyLoaded local_cache.prep_jid
[DEBUG   ] Adding minions for job 20210128041157634134: ['c1.sudo.prv']
[DEBUG   ] LazyLoaded state.apply
[DEBUG   ] Performing shimmed, blocking command as follows:
test.opts_pkg
[DEBUG   ] Executed SHIM command. Command logged to TRACE
[DEBUG   ] Child Forked! PID: 1560248  STDOUT_FD: 11  STDERR_FD: 13
[DEBUG   ] VT: Salt-SSH SHIM Terminal Command executed. Logged to TRACE
[DEBUG   ] RETCODE c1.sudo.prv: 255
[DEBUG   ] SHIM retcode(255) and command: 
Permission denied for host testhost, do you want to deploy the salt-ssh key? (password required):
testhost:
    ----------
    _error:
        Failed to return clean data
    retcode:
        255
    stderr:
        root@testhost: Permission denied (publickey,password).
    stdout:

Expected behavior
I expected it to use my username and sudo to run the states against the remote host. not just try root and fail.

Versions Report

</details>

**Additional context**
Add any other context about the problem here.

Reproduce the failure with salt-ssh against a hostname absent from the roster, using the shown roster_defaults configuration. Start at the roster_matcher.targets path visible in the debug output and trace how an unmatched host is assembled. Done means the host receives the configured user, sudo, tty, and privilege settings instead of attempting root access.