Remote podman connection: workspace mount fails with raw statfs error; no way to use a client-side project

[AranfddsqdNNN]

With a remote engine (CONTAINER_CONNECTION/CONTAINER_HOST), podman resolves
yolo's -v sources on the engine host, while yolo expands $HOME/$PWD on
the client:

~/test $ CONTAINER_CONNECTION=claude yolo
Error: statfs /home/admin/test: no such file or directory      # exit 125

• project missing on the engine → raw statfs error, no hint about the client/engine split
• path present but empty → silently empty workspace
• ~/.claude / ~/.gitconfig missing there → same failure class

Setup: rootless podman on a VM via ssh:// connection; client host has no root
and no working local engine.

Possible fixes:

1. Preflight (small fix): when remote env vars are set, verify the workspace
   source via a throwaway container, fail with an explanatory message ("bind-mount
   sources resolve on the remote engine; sync $PWD there"), warn if empty, and
   auto-create ~/.claude / ~/.gitconfig on the engine.

2. Opt-in --fuse-workspace (feature): live-serve the client's $PWD into the
   container over the podman connection itself — sshfs -f -o slave inside the
   container (--device /dev/fuse --cap-add SYS_ADMIN, sshfs added to the image),
   fed by a local sftp-server through podman exec -i (fifo+pipe bridge).
   Rootless end-to-end, no sshd/ports on the client, mount lifetime = container,
   mounted at the original $PWD so session resume keeps working. Working
   prototype exists; happy to submit it as a PR with a SPEC.md-style writeup.

Why not the obvious alternatives: podman client-side bind mounts are a still-open
upstream request (podman-container-tools/podman#8016); volume export/import is unsupported
by podman-remote; kernel 9p/NFS mounts on the VM need root.