[BUG] salt-ssh doesn't load Saltfile and doesn't expand relative paths

Description
Running salt-ssh does not load the Saltfile, and when specified on the CLI as a relative path it also doesn't load it.
When specifying the full path, it gets loaded, but the configuration inside is not expanded and the entire point of the Saltfile is moot.

I know about the other issue about path expansion (https://github.com/saltstack/salt/issues/66588), and the docs at https://docs.saltproject.io/en/latest/topics/ssh/index.html#define-cli-options-with-saltfile that do not align with reality, but the issue seems to happen with 3007.1 and 3007.0 all the same.

Setup

• Installed salt using the official package (via Homebrew) on macOS. Also try manual install just to be sure (via https://repo.saltproject.io/salt/py3/macos/minor/3007.1/salt-3007.1-py3-arm64.pkg)

• Created a Saltfile, a roster and a directory structure to hold my states and pillars etc.

.
├── Saltfile
├── env
│   ├── base
│   │   └── formula
│   └── prod
│       ├── pillar
│       └── state
├── log
├── master
├── roster
└── var
    ├── cache
    │   └── salt
    └── log
        └── salt

salt-ssh:
  root_dir: .
  config_dir: .
  roster_file: ./roster
  ssh_log_file: ./log
  ssh_max_procs: 30
  ssh_wipe: False # removes the thin client after salt-ssh is done

somehost1234:
  host: 1.2.3.4
  port: 22
  user: someone
  sudo: True

root_dir: ./

file_roots:
  base:
    - env/base/state
    - env/base/formula
  prod:
    - env/prod/state
    - env/base/state
    - env/base/formula

pillar_source_merging_strategy: recurse
pillar_roots:
  base:
    - env/base/pillar
  prod:
    - env/prod/pillar
    - env/base/pillar
yaml_utf8: True

env_order:
  - base
  - prod

Steps to Reproduce the behaviour
After installation and configuration setup:

Run a test.ping:
salt-ssh somehost1234 test.ping

Returns:
OSError: Roster file "/etc/salt/roster" not found

Manually specify Saltfile, run the same command:
salt-ssh --saltfile=Saltfile somehost1234 test.ping

Returns:
salt-ssh: error: 'Saltfile' file does not exist.

Manually specify Saltfile using the full path, run the same command:
salt-ssh --saltfile=/Users/me/salt-ssh-bug/Saltfile somehost1234 test.ping

Returns:
OSError: Roster file "./roster" not found

If I take all the paths that are referenced anywhere, and replace them with static full paths, it almost works, but it can't create keys:

salt-ssh could not be run because it could not generate keys.

I don't know in what location it is trying to create the keys, all paths are set to be the local directory I'm currently in, but I suspect that either it is being sandboxed, or it is still trying to write to somewhere in /etc, which is not what I want it to do.

Expected behavior
Consume and produce from the local directory. So when I execute salt-ssh it should read the Saltfile in the directory I am in, and either assume the relative paths are relative to the current working directory or relative to the Saltfile.

Versions Report

Salt Version:
          Salt: 3007.1
 
Python Version:
        Python: 3.10.14 (main, Apr  3 2024, 21:27:26) [Clang 15.0.0 (clang-1500.0.40.1)]
 
Dependency Versions:
          cffi: 1.16.0
      cherrypy: unknown
      dateutil: 2.8.2
     docker-py: Not Installed
         gitdb: Not Installed
     gitpython: Not Installed
        Jinja2: 3.1.4
       libgit2: Not Installed
  looseversion: 1.3.0
      M2Crypto: Not Installed
          Mako: Not Installed
       msgpack: 1.0.7
  msgpack-pure: Not Installed
  mysql-python: Not Installed
     packaging: 23.1
     pycparser: 2.21
      pycrypto: Not Installed
  pycryptodome: 3.19.1
        pygit2: Not Installed
  python-gnupg: 0.5.2
        PyYAML: 6.0.1
         PyZMQ: 25.1.2
        relenv: 0.16.0
         smmap: Not Installed
       timelib: 0.3.0
       Tornado: 6.3.3
           ZMQ: 4.3.4
 
Salt Package Information:
  Package Type: onedir
 
System Versions:
          dist: darwin 23.5.0 
        locale: utf-8
       machine: arm64
       release: 23.5.0
        system: Darwin
       version: 14.5 arm64

Additional context
This used to work with whatever version was current in 2022 (the internal repo where this configuration is stored was last committed to in 2022 and passed tests back then).